Re: [tcpPrague] Pacing IW

["Tilmans, Olivier (Nokia - BE/Antwerp)" <[e-mail]>]

Hi Bob,

 > 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/aea3ff36380bec82804eba8e3f99e5f14
 > 342978c

Note that this is disabled by default: this approach is quite fragile as
you rightfully point later on; it enables quick experimentation. I'd expect
someone willing to use this in production to have a finer-grained approach,
e.g., using the destination cache to get recent srtt/cwnd values.

 > [...]
 > - 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.

Agreed--I would expect this to happen, e.g., with PEPS terminating a
connection.

 > - 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.

Agreed. More generally, that tradeoff is extremely application dependent,
so applications sensitive to this extra delay would either not use this or
control the pacing rate used themselves by overwriting the socket max pacing
rate.

 > [...]
 > 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.

This is already the case, given the connection is seen as in slowstart (
ssthresh=infinity), the pacing rate will be (2 * IW/srtt)
https://github.com/L4STeam/linux/blob/testing/net/ipv4/tcp_prague.c#L306

 > 2. Introduce a third sysctl option (tcp_pace_iw = 2) that only paces IW
 > if srtt was initialized using the destination cache?
 
I'd happily merge any addition or better ways to do this.

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

Indeed, this was the quickest way to get it to work. It can definitely be
altered to use the destination cache, and/or to use sk_max_pacing_rate in a
smarter way (e.g.,!= infinity indicates the application explicitly
requested it before queuing data for its IW, which could/should be preferred
to any generic in-kernel computation/assumption), and/or to be CCA
independent.


Best,
Olivier

 > 
 > 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/