Re: [tsvwg] New rev of draft-ietf-tsvwg-ecn-l4s-id-17

[Sebastian Moeller <[e-mail]>]

Hi Bob,

only addressing one point, so I shortened the email a bit to make reading easier, prefixed [SM]


> On May 27, 2021, at 12:50, Bob Briscoe <[e-mail]> wrote:
> 
> David, see [BB]
> 
> On 26/05/2021 20:34, Black, David wrote:
>> Inline … --David

[...]

>> 	• Larger replay windows are a lower-effort approach that ought to apply to deployed VPNs whose replay window is configurable.  In practice, this is the place to start if L4S causes VPN problems.
> 
> [BB2] I don't disagree with making sure the replay window is large enough as well. But the IPsec and DTLS specs already say that, and it clearly doesn't always happen.

	[SM] Do you have proof that the default replay-window sizes actually cause much issues on over-the-internet VPNs without the additional systematic re-ordering L4S introduces? If yes, please post a reference/link. thanks. 


> As someone already said (Sebastian, Jonathan?), relying on a variable that gets updated only every so often, means we'll get problems every so often.

	[SM] Well, that just means in first order that we need to recommend a decent rule how to  appropriately size replay-windows for each individual VPN, based on packet-rate and RTT. The initial recommendation could be quite simple:
packet-rate [packets/ms] * expected-worst RTT [ms]
where packet rate can be approximated by:
ingress interface rate [b/ms] / average expected packet size [b/packet]
while expected-worst RTT needs to be set based on knowledge of the spatial/network distance of end points (I base this on the recommendation in the RACK RFC to limit the temporal re-ordering window to one RTT).
I understand that for short RTTs this rule faces the issue, that the L4S' induced re-ordering can be larger than the path RTT, but I assume most VPNs will be configured for longer RTTs anyway.

Personally, I would very much argue that L4S should try to keep its re-ordering as limited as possible, by keeping CE in the C-queue, after all the L4S argument goes that only one bottleneck along a path will be congested, and hence for the rest of the path queueing delay will be low already*... The treat all CE-packts ot the L-queue feels like an optimization anyway that should only be introduced after the L4S-experiment has been successful... I would imagine introducing such small tweaks would be appropriate when turning an experimental RC into a stadards track RFC...

Regards
	Sebastian


*) I am not 100% convinced that that argument actually holds water, but as long as L4S proponents use this argument, they need to accept it as valid.