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

[Mark Allman <[e-mail]>]

Joe-

You are suggesting a mechanism that does two things and trying to argue
that it is strictly more conservative.  One of these aspects seems fine
and the other seems speculative to the point I can't believe you either
don't see it or won't acknowledge it.  Let's take these in turn:

(1) Increasing the IW requires a backstop.

    The concern here is that we could get into a situation where there
    is continual use of a bad initial parameter and that will cause
    some bogosity.

    First, you're not showing this in any sort of concrete way, just
    presuming that it could happen and if it does then its bad enough to
    warrant some mitigation.  We can all dream of pathologies.  But,
    lets just put this aside for the moment and decide that given that
    we cannot fully understand the dynamics of IW10 before quite large
    scale deployment this conservativeness might be a fine design
    principle.

    So, the lets design a backstop.  To flesh out what you said in your
    last email a little, do something like this ...

      - set the default IW to 10 packets

      - if one-third of the connections (regardless of the other
        endpoint) that are able to use IW > 3 lose a packet in the
        initial cwnd then use IW=3 for the next 5min

      - if we use an IW > 3 packets and we lose at least one packet from
        the initial cwnd to some destination X then use IW=3 for
        destination X for the next minute

    The percentage (one-third) and times (1 & 5 minutes) are pulled from
    thin air, maybe they should be something else.  What we can say
    about that scheme is: (a) if we're right about IW=10 then this is a
    no-op on performance, (b) this is a minor bit of complexity and
    state, (c) if you're right that we see persistent issues then this
    will mitigate those issues, (d) this is strictly more conservative
    than a static IW=10 (not "better" necessarily, but more
    conservative) and (e) this arguably errors in the right direction
    when there is an error (i.e., it errors on the side of being less
    aggressive).

(2) We can get out of the business of setting the IW.

    This is the part where your scheme really looks like a solution in
    search of a problem.  You are positing that we can increase the IW
    adaptively by using experience from previous connections.  But, you
    are offering no evidence that we can effectively build that history.
    Jerry offered that they have tried this and found the cache hit rate
    to be quite low.  If this is the case---and his is one data point;
    at least he has that---then we're going to be dependent on the
    default IW and not on the history.

You're conflating two issues that are not intrinsicly coupled.  If you
want a backstop then call for a backstop.  If you want a way to remove
ourselves from the IW decision truck over to the lab and start working.
But, please be clear.

allman