>
> I read it quickly and have some areas in which I'm a little
> used. At the risk of showing my ignorance I've listed
> some questions and comments I have based on the draft:
>
I'll do the most embarrassing one first :o(
If we read "MSS" as "ssthresh" things are closer to what I meant :O)
(Thanks for the catch! I'm changing it now)
>
> > 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?
> > 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.
Yep, this is a hole that I had pegged as being there later on,
but this is a good place to add such a discussion (also); This one
needs to be couched with the proper qualifications as to where,
when and why this will help.
I'm actually going to place the discussion in with the top
misconception. Again, thanks!
>
> > 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?
Well, the big problems (in my mind) are:
1. If you depend on fragmenting, you increase the chances
that that a segment will be lost in the network and need
to be retransmitted
- if one or more fragments are lost in the network, the
IP datagram will not be reassembled at the receiver;
Since there is no way for fragments to be retransmitted
(reliability is done above IP), the entire segment will
need to be retransmitted.
2. You may not be able to influence the disabling of Path-MTU
discovery on the side that needs it, and even if you can, probably
don't want to as it is generally a good thing. :o)
3. Relying on fragmentation isn't a terribly neighborly thing to do
Most of the reasoning (like this) got compressed out - I'm reinflating
it now.
Eric
This archive was generated by hypermail 2b29 : Mon Feb 14 2000 - 16:14:28 EST