Subject: [tcpm] A proposal for two-party adaptive initial congestion window

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 3 Dec 2010 23:59:01 +0100 (CET)

Hi all,

we've submitted the (one more) proposal to look at in terms of gracefully 
increasing the initial congestion window - basically around the thread I had 
with Joe the other week.

https://datatracker.ietf.org/doc/draft-yourtchenko-two-party-initial-window/

We think that it should take care both of the conservative part (avoiding the 
excessive loss on poorer links) and of the progressive part (use a larger IW 
where you can).

We are thankful for your comments on this.

thanks,
andrew

---

From: Mark Allman <[email-masked]>
Date: Mon, 06 Dec 2010 22:24:26 -0500

> https://datatracker.ietf.org/doc/draft-yourtchenko-two-party-initial-window/

I read through this.  I think its overkill and likely doesn't solve any
sort of real problem.  It at least doesn't offer any argument that it
does.  The basic idea is that we take the sender IW adaption scheme that
has been sketched on the list and augment it with receiver information.
So, then, several things:

  - The basic premise of the sender adaption scheme is to setup a
    tolerance for problems caused by the IW burst.  My sketch said 5%.
    I.e., an IW works if at least 95% of the IWs are sent without loss.
    (It could be 2% and still IW=10 would work according to the Google
    data.  As a data point.)  Given this, *at most* including receiver
    side information is only of assistance in a low percentage of the
    cases because that is the failure rate of the sender-side scheme.

  - The two party scheme supposes that the receiver has insight that
    would be helpful on picking an initial window.  That may or may not
    be the case.  We have no idea where the issues with larger IWs might
    crop up (sender, receiver or middle).  But, given that the issues
    are not likely to all be at the receiver this further chops down the
    cases where this two-party adaption could possibly have any impact.

  - If the receiver knows a peer sending a larger initial burst is going
    to cause problems then that receiver can advertise a smaller
    window.  It has a control that can be applied already.

  - Trying to tightly engineer the IW is pretty meaningless because even
    if you get the receiver to help the sender in choosing a proper
    value the sender is going to then double the cwnd and probably blow
    it in the next RTT if the path is really ratty.  We need something
    *reasonable* as an initial setting, not optimal.

  - I don't find the simulations in the document to be particularly
    insightful.  The efficacy of the mechanism is based on how often
    there are persistent problems that (a) will fall within the sender's
    tolerance for problems and (b) are at the receiver such that the
    receiver can alert the sender of the issues.  To figure that out
    would require an empirical study not a series of simulations.

And, a nit:

  - Your sketch of Quick Start is wrong.  If the entire path does not
    approve of a given rate then the sender falls back to the standard
    IW and *does not* "use the full proposed bandwidth".

FWIW.

allman