Subject: Re: [tcpm] Can't we use newcwv for IW too?

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 4 Jun 2013 09:28:40 +0000

(catching up...)

> There really isn't much difference between newcwv restarting 
> after an idle period and a new connection using an IW based 
> on a previous connection's newcwv.
> We may have a new port number (although we could also be 
> extra restrictive here, if we really must), and we had the 
> FIN + SYN handshakes. These things may lead to different 
> treatment in middle-boxes and they may give us a new path, 
> using ECMP, so yes, it's not exactly the same as restarting 
> from idle, but then again, consider:
> - it takes only 1 RTT to notice the mistake and react to it; 
> this is quite close to the Jump Start idea ( 
> http://www.icir.org/mallman/papers/jumpstart-pfldnet07.pdf ), 
> but backed by prior knowledge about the path whenever stuff 
> like ECMP didn't kick in
> - we do this only for one connection following a previously 
> terminated one  (sure, if N just terminated, we could do it N 
> times, within a certain time frame...)

Since you refer to Jump Start: I am not sure if Jump Start is really similar to these current discussions.

As far as I recall, Jump Start had three interesting components:

1. Playing out the data that is available from the app in the first RTT (more precisely: the minimum of the available data and RWND)

2. Use of rate pacing in that first RTT

3. Use of a non-5681/non-6675 cwnd calculation if packet loss occurs during that inital burst

I think all three components are orthogonal to each other. Using path knowledge is probably a forth dimension.

Out of my head, my experience with the three components of Jumpstart were (I had a Linux patch for it):

1. This can be complex in practice. Apps such as Web servers don't necessarily write data in a single write() socket call. In 2008/2009, it was not simple to set cwnd during subsequent write() calls as required by Jump Start. Also, it could depend on the use case whether the server knows the data size in advance and could signal it to the TCP stack in kernel, e.g., by a socket option.

2. Rate pacing results were really mixed - IW10 had a pretty decent performance without pacing

3. The equation in the paper Section II ("(D-R)/2") does not always work - R can be larger than D in case of heavy loss. I run out of time to fully investigate the design space for loss recovery algorithms for Jump Start. In general, I am not sure if we have really well explored whether an increased aggressiveness and burstiness of TCP (IW10, etc.) could be combined with a modified loss recovery.

Michael (community member)