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

["Black, David" <[e-mail]>]

> section 6.2 with its, "use two SAs, one for ECT(1) and one for the rest" seems a bit limited

The situation is more severe than that, and it's problematic if there's any non-L4S TCP traffic that uses ECN involved.  The two SAs are actually for 2 ECN values each:

   To avoid this limitation, a VPN ingress participating in the L4S
   experiment SHOULD map packets onto two parallel SAs indexed by the
   lowest significant bit of the IP-ECN field.

That indexing puts Not-ECT [00b] and ECT(0) [10b] packets into one SA, and puts ECT(1) [01b] and CE [11b] packets into another.  Non-L4S TCP uses ECT(0) and CE, hence a flow that carries any congestion indications is split across those two SAs.  ECMP based on SPI (deployed technology) that puts those parallel SAs on different network paths is not assured to preserve packet order across those SAs, and packet reordering is not a good thing to do to a non-L4S TCP flow.

Thanks, --David

-----Original Message-----
From: Sebastian Moeller <[e-mail]> 
Sent: Friday, May 21, 2021 5:27 PM
To: Bob Briscoe
Cc: Gorry Fairhurst; Black, David; Wesley Eddy; [e-mail]
Subject: Re: [tsvwg] New rev of draft-ietf-tsvwg-ecn-l4s-id-17


[EXTERNAL EMAIL] 

Bob, chairs,

section 6.2 with its, "use two SAs, one for ECT(1) and one for the rest" seems a bit limited since it ignores that VPNs might propagate both DSCPs and ECN bits between the layers, so IMHO a better approach might be to recommend to treat DSCP+ECN bits as one aggregate byte (let's cal it TOS ;) ) as the extra ECT(1)-SA seems to be required for all SAs that already exist to deal with multiple supported DSCPs. So in a sense the recommendation would be to double the number of SAs.

Also:
"and the current draft of DTLS 1.3 says "The receiver	
 	   SHOULD pick a window large enough to handle any plausible reordering,	
 	   which depends on the data rate."  However, in practice, the size of	
 	   the VPN's anti-replay window is not always scaled appropriately."

L4S on a 10 ms path under load can introduce re-ordering in the range of 50 ms (roughly twice the difference between the L- and C-queue delay targets), re-ordering tolerance 5 times of the path RTT seems to be a bit on the high side to expect, no?




Regards
	Sebastian


> On May 21, 2021, at 11:21, Bob Briscoe <[e-mail]> wrote:
> 
> Chairs, list,
> 
> We've posted a new rev of draft-ietf-tsvwg-ecn-l4s-id-17 attempting to address all the discussion since the last posting just before the interim. In particular:
> * review comments on a careful read from Gorry and the chairs
> * the VPN anti-replay problem
> * added an out-of-band test for an RFC3168 ECN AQM in a shared queue.
> 
> There are a couple of outstanding discussions, which I'm sure will continue on the list, e.g. the role of RFC4774 and whether to remove any of Appx C. But it was considered better to get the queued up changes out, to re-base the discussions.
> 
> This is quite an extensive set of changes, so pls check and pass any comments to the list.
> 
> Thanks for everyone who is contributing, and particularly to the chairs for continuing to referee this all. We've added appropriate thanks in the Acks section.
> 
> 
> Bob
> 
> 
> On 21/05/2021 10:09, [e-mail] wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>> 
>>         Title           : Explicit Congestion Notification (ECN) Protocol for Very Low Queuing Delay (L4S)
>>         Authors         : Koen De Schepper
>>                           Bob Briscoe
>> 	Filename        : draft-ietf-tsvwg-ecn-l4s-id-17.txt
>> 	Pages           : 57
>> 	Date            : 2021-05-21
>> 
>> Abstract:
>>    This specification defines the protocol to be used for a new network
>>    service called low latency, low loss and scalable throughput (L4S).
>>    L4S uses an Explicit Congestion Notification (ECN) scheme at the IP
>>    layer that is similar to the original (or 'Classic') ECN approach,
>>    except as specified within.  L4S uses 'scalable' congestion control,
>>    which induces much more frequent control signals from the network and
>>    it responds to them with much more fine-grained adjustments, so that
>>    very low (typically sub-millisecond on average) and consistently low
>>    queuing delay becomes possible for L4S traffic without compromising
>>    link utilization.  Thus even capacity-seeking (TCP-like) traffic can
>>    have high bandwidth and very low delay at the same time, even during
>>    periods of high traffic load.
>> 
>>    The L4S identifier defined in this document distinguishes L4S from
>>    'Classic' (e.g. TCP-Reno-friendly) traffic.  It gives an incremental
>>    migration path so that suitably modified network bottlenecks can
>>    distinguish and isolate existing traffic that still follows the
>>    Classic behaviour, to prevent it degrading the low queuing delay and
>>    low loss of L4S traffic.  This specification defines the rules that
>>    L4S transports and network elements need to follow with the intention
>>    that L4S flows neither harm each other's performance nor that of
>>    Classic traffic.  Examples of new active queue management (AQM)
>>    marking algorithms and examples of new transports (whether TCP-like
>>    or real-time) are specified separately.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-l4s-id/__;!!LpKI!xeGDaVTRL33QRdX3Tos2AURXirtYtZXHcEP8W5a6OO_m4gWSHU68p06V9qj70HfR$ [datatracker[.]ietf[.]org]
>> 
>> There is also an htmlized version available at:
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-ecn-l4s-id-17__;!!LpKI!xeGDaVTRL33QRdX3Tos2AURXirtYtZXHcEP8W5a6OO_m4gWSHU68p06V9vC50L2Y$ [datatracker[.]ietf[.]org]
>> 
>> A diff from the previous version is available at:
>> https://urldefense.com/v3/__https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-ecn-l4s-id-17__;!!LpKI!xeGDaVTRL33QRdX3Tos2AURXirtYtZXHcEP8W5a6OO_m4gWSHU68p06V9oZoDRib$ [ietf[.]org]
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> https://urldefense.com/v3/__ftp://ftp.ietf.org/internet-drafts/__;!!LpKI!xeGDaVTRL33QRdX3Tos2AURXirtYtZXHcEP8W5a6OO_m4gWSHU68p06V9rKXcwvA$ [ftp[.]ietf[.]org]
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               https://urldefense.com/v3/__http://bobbriscoe.net/__;!!LpKI!xeGDaVTRL33QRdX3Tos2AURXirtYtZXHcEP8W5a6OO_m4gWSHU68p06V9gj_uPXC$ [bobbriscoe[.]net]
>