Re: [tcpm] informal poll about initial cwnd

Fwiw, I prefer us going with (C) as well. A static value always has the problem that it has to be revisited frequently and there is no guarantee that it is correct for a given environment. Some implementations may be more aggressive than others in setting the static value by not following the standard spec as well.

As we have seen from the many discussions on tcpm on IW, the problem is complex to solve. So I am not sure if we can reach consensus quickly on the algorithm to increase/decrease IW. In the spirit of making forward progress, perhaps it makes sense to increase the IW "somewhat" statically (option A) and continue to work on the dynamic algorithm proposal.

Also the loss distribution across all connections on a host is not uniform when that host has connections to destinations on widely varying networks (LANs and WANs). In a perfect world, path heuristics of each connection should play into the algorithm (RTT, delay, local/remote destination) so that the least lossy connections get the highest IW versus the most lossy connections getting lower IWs.

Cheers,
Anumita.

-----Original Message-----
From: Scheffenegger, Richard 
Sent: Thursday, January 06, 2011 2:14 PM
To: John Heffner; mallman@icir.org
Cc: tcpm@ietf.org
Subject: Re: [tcpm] informal poll about initial cwnd

Certain implementors have already choosen, if the points in Dave's presentation are adopted to main linux, for all I know.

For the record, given the simplicity I would prefer (A) for low-end / "closed" environment applications, and (C) for high-volume + public deployments (ie. Home users/corporate intranets could do with a single updated IW; operators who could have an impact on a larger (global) scale to the public internet, should go with (C) - adding some accountability, basically).

Regards,
   Richard

> -----Original Message-----
> From: John Heffner [mailto:johnwheffner@gmail.com]
> Sent: Donnerstag, 06. Jänner 2011 22:20
> To: mallman@icir.org
> Cc: tcpm@ietf.org
> Subject: Re: [tcpm] informal poll about initial cwnd
> 
> As a firm believer in simplicity where possible, I have strong
> reservations on (C).
> 
> If approach (D) is chosen, implementors will very soon start making
> their own choices for non-standard IW.  It's not clear to me this is a
> bad thing, but it could be.
> 
>   -John
> 
> 
> On Thu, Jan 6, 2011 at 1:19 PM, Mark Allman <mallman@icir.org> wrote:
> >
> > Given that there are three proposals put down in I-D form in some
> matter
> > of baked-ness I am wondering if there is any sort of clear WG
> preference
> > on the *approach* to changing the initial window.  So, putting aside
> the
> > particulars for a moment and just thinking about the approach I'd
> like
> > to take a quick, informal, absolutely non-binding in any way
> (obviously)
> > poll to take the WG's pulse.
> >
> > So, do you prefer ...
> >
> > (A) To increase the current static IW definition to a single updated
> >    value.
> >
> >    (Current proposal: draft-ietf-tcpm-initcwnd-00.txt, but I am
> >    explicitly not asking about IW=10, just IW=some_X.)
> >
> > (B) To increase the current static IW definition with a schedule of
> IW
> >    updates to play out over some period of time.
> >
> >    (Current proposal: draft-allman-tcpm-bump-initcwnd-00.txt, but I
> am
> >    explicitly not asking if you like the given schedule.)
> >
> > (C) To define a procedure for hosts to figure out how to adapt their
> IW
> >    over time.
> >
> >    (Current proposal: draft-touch-tcpm-automatic-iw-00.txt, but I am
> >    explicitly not asking if you buy the particulars of this, just the
> >    overall approach.)
> >
> > (D) The current IW seems OK and I haven't seen a good reason to think
> it
> >    needs changed.
> >
> > Thanks!
> >
> > allman
> >
> >
> >
> >
> > _______________________________________________
> > tcpm mailing list
> > tcpm@ietf.org
> > https://www.ietf.org/mailman/listinfo/tcpm
> >
> >
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm