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]
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST