Form: Reply
Text: (11 lines follow)
Eric,
Please tell me this is a Fraudian slip.
2.2 Common Misconceptions about TCP
2.2.1 TCP does work in satellite environments
Absolutely wrong regardless !!!
I hope that should be 2.2.1 TCP does NOT work in satellite environments
Absolutely wrong regardless.
Matt
Original text: (79 lines follow)
>From AARON@SMTPGATE (Aaron Falk)
{Aaron.Falk%[email protected]}, on 4/8/97 2:17 PM:
To: E@SMTPGATE (Eric Travis) {[email protected]}
Cc: TCP-OVER@SMTPGATE (tcp-over-satellite)
{[email protected]}
Eric-
Many thanks for getting the draft out. It was clearly a huge
effort (bigger than I expected). You have come up with a
very thorough toxonomy of the problem.
I read it quickly and have some areas in which I'm a little
confused. At the risk of showing my ignorance I've listed
some questions and comments I have based on the draft:
> 2.2 Common Misconceptions About TCP
>
> [...clip...]
> 2.2.4 ???
>
2.2.4 Adding sufficient memory at satellite uplink router
can fix problem
* I've heard several mentions (not on this list) that if
you make your windows big enough and add a lot of
memory at the uplink, throughput problems can be
overcome.
> 4.2.1.2 Path-MTU Discovery
>
> As mentioned earlier, the MSS employed on a connection has a large
> impact on the rate at which the congestion-window grows while within
> slow-start.
>
> In order to prevent the inefficiencies of IP-fragmentation, many
> modern TCPs employ Path-MTU Discovery
>
> o Each "failure" will cost ~RTT of delay (assuming that pipe-constriction
> is on the far-end of the satellite link from the sender.
>
> o Ideally, don't we want to send as big a segment as possible
> (regardless of fragmentation) because of the rate of cwnd growth.
>
If you are going to ignore fragmentation "costs", then I
don't understand why you wouldn't want to send as large a
segment as possible. Is it because more smaller segments
opens the window (in # of segments) faster than fewer large
segments? For small transfers wouldn't that be preferable
since the round trip time is what's killing you?
> 4.2.5.1.3 Better initial ssthesh estimation
>
> Instead of basing MSS on the initial advertised window, attempt
> to avoid multiple packet losses (to terminate slow-start) by
> terminating slow-start *just in time* by using a more accurate
> estimate of the bandwidth-delay product.
>
Here I am really confused. ;-) What is the connection
between initial ssthresh, MSS, and initial advertised
window?
Again, great job!
aaron
-- Aaron Falk (310) 814-4932 TRW, Inc Electronics Systems & Technology Division [email protected]Use Proportional Font: true Previous From: AARON@SMTPGATE (Aaron Falk) {Aaron.Falk%[email protected]} Previous To: E@SMTPGATE (Eric Travis) {[email protected]} Original to: E@SMTPGATE (Eric Travis) {[email protected]} Previous Cc: TCP-OVER@SMTPGATE (tcp-over-satellite) {[email protected]} Original cc: TCP-OVER@SMTPGATE (tcp-over-satellite) {[email protected]} Attachment Count: 0
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST