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

[Jakob Heitz <[e-mail]>]

IMHO:

If you think a small TCP IW is protecting any network from
congestion collapse, you are either living in the past
or under delusions of grandeur.

Today's networks are under greater threat from many protocols
that have no respect for congestion control at all and
would collapse immediately without QOS.

TCP IW protects the TCP session itself.
The problem with TCP is that if it drops too many packets, it
grinds to a halt. That is to be avoided at all costs.
A small IW helps to avoid that.
Of course too small an IW makes it take too long to ramp up.
There is no good way to find the optimum. The best seems to
be history of previous connections.

It probably should not even be standardized.
Remove the IW recommendation from the standard and
let each implementation figure out its own optimum.

--
Jakob Heitz.
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of David Borman
> Sent: Wednesday, November 17, 2010 11:03 AM
> To: Alexander Zimmermann
> Cc: tcpm
> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes
> 
> I've been thinking about the whole IW issue, and trying to 
> step back a bit from IW itself.  So I ask myself, what is the 
> main issue with having a large IW?  If the network has the 
> bandwidth, there isn't any practical problem.  But if the 
> network doesn't have the bandwidth, a bunch of TCP 
> connections starting up with a larger IW can lead to 
> congestion.  So then I ask myself, what is wrong with 
> congestion?  The data is going to back up somewhere, so does 
> it matter?  Of course, the answer is that yes, it does 
> matter, because we don't have a lossless network.  When there 
> is congestion in routers, if there isn't enough buffering, 
> the way to deal with that is to drop packets, which in turn 
> leads to retransmissions.
> 
> But I don't think it is congestion itself and the dropping of 
> packets that is the problem, the issue is we don't want that 
> congestion to turn into congestion collapse.  So, it seems to 
> me that the issue about whether or not it is safe to increase 
> the IW should be focused more on, if increasing the IW leads 
> to increased congestion, is the network still able to 
> properly respond to that congestion and avoid congestion 
> collapse?  If the answer is "yes", then I think that greatly 
> reduces the risks of increasing the IW.  But if the answer is 
> "no", then we have a bigger problem that is lying in wait and 
> can be triggered by other factors than just increasing the IW.
> 
> 			-David Borman
> 
> 
> On Nov 17, 2010, at 1:58 AM, Alexander Zimmermann wrote:
> 
> > Hi Richard,
> > 
> > exactly, this is the point!
> > 
> > IMO, two things are crystal clear:
> > 
> > 1. We have to touch/increase the IW
> > 2. We have to do it now
> > 
> > Also, IMO he have a rough consensus on these two points.
> > 
> > What I like two see now, or discuss now, is a strategy how 
> we can progress.
> > 
> > Mark proposed something, but what are thoughts from the 
> document author/
> > other group members/chairs/AD on this point?
> > 
> > Alex
> > 
> > Am 16.11.2010 um 17:41 schrieb Scheffenegger, Richard:
> > 
> >> 
> >> Group,
> >> 
> >> Just one additional data point: Obviously, there are 
> already applications in the wild, that use persistent 
> connections and disable the slow-start-restart mechanism on 
> these sessions. The expectations of the programmers making 
> use of these socket options is to reduce the latency for 
> their appliaction... In effect, these Apps seem use IW=44 
> (and hurting themselves more than anybody else).
> >> 
> >> See "Profiling Network Performance in Multi-Tier Data 
> Center Applications", Section 6.1, "cwnd failing to prevent 
> sudden bursts", http://www.cs.princeton.edu/~jrex/papers/snap10.pdf
> >> 
> >> 
> >> IMHO this is evidence that some action in this space is 
> absolutely needed (even if it is "only" strong advice to apps 
> programmers), or there will be even more proliferation of 
> clumsy workarounds that are even less well understood and 
> investigated than IW10 already is. Keeping IW3 "forever" may 
> be more problematic than addressing emerging application 
> needs with well-tested transport-layer approaches...
> >> 
> >> 
> >> Richard Scheffenegger
> >> 
> >> 
> >>> -----Original Message-----
> >>> From: Fred Baker [mailto:[e-mail]] 
> >>> Sent: Dienstag, 16. November 2010 15:10
> >>> To: "Ilpo Järvinen"
> >>> Cc: tcpm; tmrg
> >>> Subject: Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes
> >>> 
> >>> 
> >>> On Nov 16, 2010, at 10:01 PM, Ilpo Järvinen wrote:
> >>> 
> >>>> On Tue, 16 Nov 2010, Fred Baker 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.
> >>>> 
> >>>> It only "disables" it if there was no congestion to 
> control in the 
> >>>> first place.
> >>> 
> >>> How do you turn off something that's not on?
> >>> 
> >>> I refer to this as in the average case turning off congestion 
> >>> control because the transmission requires ten data packets 
> >>> and they all get sent in a single burst. There is no 
> >>> congestion control, with IW=10, in the case of the 
> >>> average-sized (which is actually gar above the median-sized) 
> >>> file transfer.
> >>> 
> >>>> Could you on your behalf answer how does IW=3 affect 
> >>> parallel sessions 
> >>>> on the same kind of environment? ...I've done research 
> on this (and 
> >>>> Jerry has
> >>>> too) and I know that the answer is not an intuitive one. Then we 
> >>>> changed to IW10 in the same environment and observe no 
> (consistent) 
> >>>> change. The results are driven by problems already with 
> IW3 so IW10 
> >>>> won't make it any worse or the effect is just too small to 
> >>> be measured 
> >>>> among the other troubles that happen.
> >>> 
> >>> That may be true. I have asked to see data describing the 
> >>> impact. I haven't seen the data. Maybe I missed something?
> >>> _______________________________________________
> >>> tcpm mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/tcpm
> >>> 
> >> _______________________________________________
> >> tcpm mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tcpm
> > 
> > //
> > // Dipl.-Inform. Alexander Zimmermann
> > // Department of Computer Science, Informatik 4
> > // RWTH Aachen University
> > // Ahornstr. 55, 52056 Aachen, Germany
> > // phone: [phone], fax: [phone]
> > // email: [e-mail]
> > // web: http://www.umic-mesh.net
> > //
> > 
> > _______________________________________________
> > tcpm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tcpm
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>