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

[John Heffner <[e-mail]>]

I completely agree with everything Mark said.  A couple questions,
though:  Do we have to go through this every ten years?  Do
implementors really need the IETF's blessing on some particular IW
value?  Do we want to put ourselves in that position?  The IETF is not
terribly good at weighing trade-offs, where a change might benefit
some at the expense of others.  Maybe we can issue some broader and
longer-lasting guidance.

Thanks,
  -John


On Thu, Nov 11, 2010 at 12:42 PM, Mark Allman <[e-mail]> wrote:
>
> I have inhaled the initial window thread and have some thoughts ...
>
>  + Altering the initial window is not a *fundamental* change to TCP.
>    It is a *parameter* tweak.  Certainly parameter tweaks can have
>    negative and broad implications, but lets show some perspective
>    here.
>
>  + Likewise, changing the initial cwnd **does not remove CC**.  As a
>    connection gets feedback from the network path it does what it has
>    always done and reacts to its observations.  So, a problematic
>    initial window size will in fact get corrected.
>
>  + It is not true that somehow using an initial cwnd of 10 packets
>    makes that the minimum cwnd size.  TCP has mechanisms to lower the
>    cwnd if that is necessary.
>
>  + Nobody is mandating using a cwnd of 10 packets.  If a host is in a
>    particular situation whereby less would be better then it can use
>    less (either by tuning its own initial cwnd or by appropriately
>    setting the advertised window).
>
>  + Is this HTTP-centric?  Well, maybe.  It is medium transfer
>    size-centric.  HTTP is a big component of those transfers at
>    present.  But, I don't follow why this is a big deal.  This seems
>    like a red herring to me.
>
>  + Adjusting a parameter is not renouncing the conservativeness
>    principle.  It is perfectly natural for a parameter like this to
>    evolve over time as networks evolve.  Just because there used to be
>    excessively low speed networks doesn't mean that somehow we need to
>    be bound by that for the entire future.  And, adjusting for
>    "inflation" doesn't somehow abdicate the principle of being
>    conservative.  Put another way, conservativeness and aggressiveness
>    are relative and we are merely trying to find a reasonable tradeoff
>    here.
>
>  + Further, there are always *current* networks that lag behind.  At
>    some point we have to decide that our engineering is going to be for
>    the 99.9% common case and the outliers are going to have to deal
>    with it.  People lodged the complaint that there were slow networks
>    when we moved from one packet to three.  That will always be the
>    case.  I'm not saying if you're in the minority we forget you here.
>    If this change is good for only 51% of the cases then it is not a
>    good change.  But, because we have an existence proof of some spot
>    that cannot cope with a 10 packet burst does not mean this is a bad
>    idea.
>
>  + Just because IW=10 causes loss doesn't mean it hurts performance.
>    Jerry, et.al. have testbed experiments that show this.  The steady
>    state loss rate of a TCP is a key component of performance.  But,
>    that doesn't mean loss in the initial window dictates long-term
>    performance.  If a network can only support a window of three
>    packets then the performance is going to be lousy regardless of the
>    initial window.  A larger initial window is not likely to change the
>    overall performance---as the experiments illustrate.
>
>    (There is the chance that in the case of multiple congested gateways
>    that the extra packets will consume scarce resources and therefore
>    impact other flows.  But, with excessively low capacity networks it
>    is really hard to envision the initial cwnd as being the thing that
>    makes the network lousy.)
>
>  + Maybe this exacerbates the case of long queues in home networks.
>    But, (1) I doubt its a big deal and (2) that isn't exactly TCP's
>    problem.  On my DSL line I never build a perceptible queue on the
>    downlink.  On the uplink I do.  If I am doing the math right my
>    uplink would build a 1sec queue at 10 parallel connections using
>    IW=10 and starting at the same time.  But, that seems like a pretty
>    thin use case.  I.e., I never start that many connections and pump
>    data into them in that fashion.  I might start that many connections
>    / second, but I put 300 bytes of HTTP GET in there or the like.  In
>    the cases where I can think of that you would start connections at a
>    high rate (at least in a burst) and then pump data into them
>    (e.g. BitTorrent) you're going to build this queue anyway.  And, it
>    just isn't clear to me that we need to somehow make TCP "solve" this
>    problem because fundamentally we just need less buffering.
>
>  + Allowing apps to tune the IW via a socket option seems pretty
>    pointless to me.  I doubt the application is in any sort of position
>    to pick wisely.  If they do anything but turn it to the maximum
>    allowed it would be pretty surprising, I think.
>
> While perhaps we can say the onus is on the proposers to convince us, it
> seems as though Jerry et.al. have done all the experiments that comments
> have pointed to.  If you have a concrete problem with the proposal it'd
> be nice to see that in concrete terms---experiments---instead of hand
> waves.
>
> FWIW.
>
> allman
>
>
>
>
> _______________________________________________
> Tmrg-interest mailing list
> [e-mail]
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/tmrg-interest
>
>