Re: [tcpm] alternate IW proposal

[Mark Allman <[e-mail]>]

> >    - The cross connection dynamic is presuming you're making the same
> >      mistakes over-and-over.  That isn't clear.  If you make a zillion
> >      10 packet connections to some host then OK.  I am willing to call
> >      that pathological.
> 
> Let me be more clear. The IW isn't a property of the destination,
> it's a property of the path. 

No it isn't.  The IW is a construct of the sender.  The path DOES NOT
HAVE A WINDOW, LET ALONE AN **INITIAL** WINDOW.  Period.

Congestion is a property of a particular link.  And, congestion of
individual links aggregate into the congestion experienced across a
path.  But, there is no way to, e.g., measure the "IW of a link".  That
doesn't make any sense.

TCP has a system of *inferring* congestion along the network path a
connection traverses (putting aside ECN, which isn't much used).  And,
it has a construct called a "congestion window" to regulate the current
sending rate based on its observations of that path.  When a connection
starts it does not have a history of observations on which to base its
congestion window (/ sending rate).  Yet, it needs some initial rate.
So, we have to have some default here.  None of this is new or novel or
startling.

So, we use some default IW.  That default IW is a probabilistic
engineering *guess* at its root.  We use something that we believe will
work well in the vast majority of the cases and when it doesn't the
results are not somehow catastrophic.

    (It *could* have a history as you have noted (and conducted research
    on).  But, the practical efficacy of that has at least not been
    shown (as far as I know; perhaps I am out of the loop).  E.g., how
    often do two hosts communicate?  And, is it meaningful to cache
    across the timeframe between those communications?  E.g., even if
    you think you're talking to a particular host you may be talking to
    a farm and your connection gets sprayed to the "best" possible
    server at some moment in time (for some secret-sauce definition of
    "best") and that server might not have the state from your last
    interaction.  Etc.  So, I agree that this is something we can think
    further about and it may well be that it is nice for things like
    repeated image gets from some web server.  However, that does not
    get us away from needing some initial setting.  At *best* you have
    reduced the importance of the setting in some cases.)

> >    - The vast majority of traffic volume is from large flows that
> >      converge via the usual AIMD.  Therefore, by traffic volume the
> >      initial window is a quite small effect---especially if we are
> >      roughly in the area of "reasonable" (i.e., if the 10 packet window
> >      works the vast majority of the time).
> 
> IW traffic is bursty, and bursts tend to synchronize. Further, IW is
> uses more than just for the connection start - it's also used for
> restart, e.g., after an idle period.  

I would be perfectly happy with a rule that said the RW had to be
min(IW,max_lossless_cwnd/2).  I.e., basing the RW on observations from
the connection itself seems absolutely reasonable to me.

> How much does this help? How much does it reduce latency? Most of
> the info I've seen summarized suggests the benefit is in the 5-20%
> range. That's not even noticeable from a user POV.

20% seems like a pretty nice chunk of change to me.  That's on the order
of what we got by going to 4KB.  20% of a second is perceptible to
humans.  Add this over a number of objects and it looks like a fine bit
of increase to me.  Certainly this WG has done things for much less
benefit. 

allman