Re: [tcpm] informal poll about initial cwnd

A) for me; it is simple.

C) is great for sophisiticated implementors with a sophisticated infrastructure
to suppport the implementation, which I think will often not be the case.
Perhaps
one for an xxxRG not a WG.

D) I do not believe will ever happen.

Tom Petch

----- Original Message -----
From: "SCHARF, Michael" <Michael.Scharf@alcatel-lucent.com>
To: <tcpm@ietf.org>
Sent: Friday, January 07, 2011 12:04 AM
Subject: Re: [tcpm] informal poll about initial cwnd

> I would allow (A) because of its simplicity, but the same I-D should
> also mandate implementors to carefully monitor the impact and strongly
> recommend to revert to IW3 if any harm is observed. As one potential
> (recommended?) solution for this, it could propose a procedure somehow
> along the lines of (C).
>
> IMHO implementors MUST really carefully monitor the impact of an
> increased IW, in particular for large-scale deployments. This can be
> done by a procedure similar to draft-touch-tcpm-automatic-iw-00, but
> probably also by other control loops, e. g., by regularly monitoring
> transaction times at application level. The IETF should describe one
> application-agnostic way of monitoring the impact of a larger IW, but
> also allow implementors to come up with other solutions.
>
> Michael
>
>
> > -----Original Message-----
> > From: tcpm-bounces@ietf.org [mailto:tcpm-bounces@ietf.org] On
> > Behalf Of Mark Allman
> > Sent: Thursday, January 06, 2011 7:20 PM
> > To: tcpm@ietf.org
> > Subject: [tcpm] informal poll about initial cwnd
> >
> >
> > 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