[tcpPrague] Pacing IW

[Bob Briscoe <[e-mail]>]

Olivier,

I notice you've pushed code to TCP Prague, to optionally pace out IW 
over the estimated rtt (srtt).
https://github.com/L4STeam/linux/commit/aea3ff36380bec82804eba8e3f99e5f14342978c
Thanks for this. Some thoughts:

srtt can tend to be rather wildly wrong at the start of a connection. 
I'd say a high estimate will be more concerning than a low, by this 
reasoning:

- If the initial srtt estimate is too low, there will be a queuing delay 
spike, but it will never be worse than just sending IW at line rate.
- If srtt is too high, a short flow would take longer to complete 
because the first ACK will return before the IW has finished sending.

I recall Mark Handley presenting data showing longer RTT outliers at the 
start of connections (cause was unknown, but could have been a CDN 
getting its act together to serve the connection from an optimal 
location). Sorry, can't find the paper - it was perhaps 5-10 years ago. 
Whatever, in general, an over-high initial estimate is surely more 
likely than over-low, given the initial handshake might be delayed more 
than other packets, but it's unlikely to find some worm-hole that gets 
it back home faster than the speed of light.

So, possible solutions (either or both):

1. In tcp_prague.c, multiply the rate returned from 
prague_update_pacing_rate() by N(where N=2, say). So IW is at least 
paced over the first half of the RTT on average. Then, if the initial 
srtt estimate is longer than reality, the error has to be 2x before IW 
will be delayed more than a whole round.
2. Introduce a third sysctl option (tcp_pace_iw = 2) that only paces IW 
if srtt was initialized using the destination cache?


Altho this is in TCP Prague now, I guess eventually it could be taken up 
by any transport with any CC.

Cheers


Bob

PS. Defensive coding nit: In tcp_output.c, I noticed you've kept the 
condition
     if ( ... || tp->data_segs_out >= 10 )
Surely this shouldn't have been a hard-coded '10' in the first place?

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/