Re: [tcpm] Increasing the Initial Window - Notes

["Scheffenegger, Richard" <[e-mail]>]

Hagen,


Regarding cached cwnd: that would assume that you already have some past
expirience with the host (a), but also that your previous interaction
was transporting enough (bulk) data to arrive at some steady state(b)...

>From my understanding, for the suggested use case (minimize delivery
latency of "small" flows, sent out of big server farms), that might not
be possible to achive. Or am I wrong?


For your use case (networks with small BDP), shouldn't the receiver be
able to signal an accordingly small window (in comparison with the
window which is likely being signalled when the user is connected to a
fat pipe)?

(Is there are correlation between configured tcp receive window size,
and maximum bulk transfer speeds within the public internet? Or are
default parameters used without correlation to the actual possible bulk
transfer speeds?)


I have mentioned this earlier (but got swayed a bit) that some cheap
home gateways may have very small buffer sizes, which could be
overwhelmed as well if initcwnd=10 is used. OTOH, your average server
does not reside beind a home gateway box (and if, you may be inclined to
upgrade that box for more reliable service anyway)...

As you say, bursting 10 MSS segments at wirespeed onto a bottleneck
might not be all that bright an idea, especially if the bottleneck is
close to the sender, and runs at a significantly lower speed (ie. 1Gbps
internal, 54Mbps phys public, rate limited to 1Mbps)

Just a thought:

Perhaps pacing or chirping (inverse chirping, to be specific) can be
used to address the issue of burst overloading a small first hop queue;
for internet RTTs, the pacing interval would still be minuscle, but
would allow the queues to drain somewhat...

   __            __ __ __ __  __   __    __     __      __       __
__|S |_/~/_    _|D |D |D |D ||D |_|D |__|D |___|D |____|D |_____|D
|_/~/_   _/~/_   ....
           |SA|
|A|     |A|                    

Obviously, that would need somewhat more fine-grained tcp timers (ie.
1ms, with the pacing/chirping interval increasing by some factor for
each additional segment sent, until a new, higher initcwnd is reached,
or the ACK from the receiver starts the ACK clock...)

That would be similar to the RTO backoff, just with a couple magnitude
smaller timescales, and the sending of new data instead of the resending
of the same data... Also, we wouldn't necessarily have a discussion for
any arbitrary initcwnd soon again ;)



Wasn't there a study to be conducted on the behavior of home gateways
(queue depths, forwarding rates, behavior on unknown tcp options etc)?

I think for Africa / South America, if initcwnd is used on server side
(and the bottleneck bandwidht likely to be approched in multiple, small
steps) there was some research presented since maastricht, not?



Richard Scheffenegger
 

> -----Original Message-----
> From: Hagen Paul Pfeifer [mailto:[e-mail]] 
> Sent: Mittwoch, 10. November 2010 17:29
> To: Anantha Ramaiah (ananth)
> Cc: tmrg; Matt Mathis; tcpm
> Subject: Re: [tcpm] Increasing the Initial Window - Notes
> 
> * Anantha Ramaiah (ananth) | 2010-11-10 08:04:48 [-0800]:
> 
> >I think the stuff which you are suggesting below has already been 
> >mentioned in earlier conversations (mailing lists, online during the 
> >earlier presentations). Things like "tomorrow someone will 
> come with IW 
> >= 23 etc.,", using the cached information also has been 
> mentioned. The 
> >IW=10 is a fundamental change to TCP and hence the 
> suggestion of moving 
> >this work item to ICCRG also was mentioned before. Someone 
> also pointed 
> >out "will this work in Africa"?  Also using a TCP option to 
> agree upon 
> >the IW was mentioned (which is probably less useful since 
> you have to 
> >wait for the 3 way HS to complete and also it is not about end hosts 
> >supporting higher IW, it is about the network property as 
> you rightly 
> >mention below)
> 
> I am aware about "IW >= 23" and the Africa discussion. For me 
> the later is a strong reason for a refusal of the draft. I am 
> not aware of the discussion of the _cached cwnd_ approach.
> 
> Hagen
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm
>