Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[Jerry Chu <[e-mail]>]

On Mon, Nov 15, 2010 at 8:07 PM, Fred Baker <[e-mail]> wrote:

>
> On Nov 11, 2010, at 7:48 AM, Jerry Chu wrote:
>
> > I wonder what factors will argue that the initial quantum can't be
> changed?
> > Someone has argued in the past IW10 effectively "disable CC algorithm".
> > But haven't we already done that years ago when moving up IW from 1 to 3
> if
> > one insisted then that the initial quantum must be 1?
>
> Actually, no. I may be the person who said that this effectively disables
> congestion control in the average case; my reason for saying that is that
> per what little data I have, the average TCP transfer is on the order of 15K
> bytes, which is about ten 1460 byte segments.
>
> Now, the median is much smaller - on the order of two or three data
> segments each direction, which is where you get your comment. But the fact
> that browsers, Bittorrent, and other applications open multiple sessions
> simultaneously argues that a given endpoint having multiple packets in
> flight simultaneously doesn't hurt, and research done at the time by Mark
> Allman and others showed that IW=2..4 wasn't a problem and did in fact
> reduce the median session to a single RTT for data. But the median session
> doesn't create a congestion problem.
>
> The question I have been asking is how IW=10 affects parallel sessions on
> relatively low speed links. My sense is that the sudden arrival of O(15K)
> bytes at a 56 KBPS line, which is to say the insertion of a tad over two
> seconds delay in all competing sessions plus an increase in their
> probability of loss, is likely to cause them all to be disrupted. You told
> me verbally that in your tests it is net beneficial to the parallel
> sessions, but in thought experiments I'm not sure how that can be true; I'd
> be


Perhaps you've missed something in your thought process? In addition to some
points
Ilpo has made in his reply, another plausible explanation that you may not
have
considered is that for the same amount of data to be transfered, IW10 is
simply more
"efficient" in average than IW3. It is true that IW10 causes a larger burst
to be sent,
but it is not like you're going to get the same frequency of 10-pkt bursts
as compared
to 3-pkt bursts. The comparison is more like a single large burst vs three
smaller
bursts. It's not clear to me one can actually prove the single large burst
will often
cause more damage to competing flows than 3 smaller bursts and our testbed
sorta
confirmed this.

Jerry


> fascinated to see the data that shows that competing voice/video sees no
> frame loss or induced noise, that competing file transfers slow down but do
> not see redundant retransmissions, and so on.
>
> So, IW=2..4 demonstrably works pretty well everywhere, but IW=10 seems to
> me only sensible on MPBS and GBPS, not KBPS, scale links.