[tsvwg] SCE / L4S and fragmentation (was: Status of ECN encapsulation drafts (i.e., stuck))

Bob Briscoe <ietf@bobbriscoe.net> Fri, 13 March 2020 15:36 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0FB8C3A0C8C for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 08:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.432
X-Spam-Status: No, score=-1.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9BRO-YuM4ciz for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 08:36:02 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B97D3A0C85 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 08:36:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=natQTlvnkJs0aI72N7hCgpGvsDn5MJWhncFy+6z7Fl8=; b=MGsDCNHy89QTkpCPk+jqabGVy 2sTl5IfxxQmqW2GK36sgvrzZ+PHpWAbOZJ3tBMnMw7MS0bWWXR8Ns+67XCtrM68aU5ujnQF4fHKAy fszACHO7lqUwDXP4amM2rmWrROI8QpquxW0m+sJ7k51oowpg1B+h49qZ+vET3YKaYXjNf8F+Yc1+3 M6OlHqToL/Qd1mVIgyUra4wqZ21qsBX8ECUxD80xJGwgOAZb2jfgvJp1YIfMu8z9xCLN3lJGFcNCW UG7HjAtHYugtrMszuK3jwYt0++axQmlIU3U0AsykiNYAHABKi2YnKCDJ1iX6LwiVqtXhrjcUaZ+ZO 5gJSzNNZw==;
Received: from [] (port=38774 helo=[]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <ietf@bobbriscoe.net>) id 1jCmLv-00FCLO-RN; Fri, 13 Mar 2020 15:36:00 +0000
To: Jonathan Morton <chromatix99@gmail.com>
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <f0a789a0-8bb8-11d9-e8f1-c0570e959151@bobbriscoe.net>
Date: Fri, 13 Mar 2020 15:35:58 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com>
Content-Type: multipart/alternative; boundary="------------32781D6D8EBBD466A395E3C6"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - bobbriscoe.net
X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/hyS7dcJ7ask-1ki5XcetpBI8OE4>
Subject: [tsvwg] SCE / L4S and fragmentation (was: Status of ECN encapsulation drafts (i.e., stuck))
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Mar 2020 15:36:06 -0000


On 10/03/2020 23:02, Jonathan Morton wrote:
> The existing language in RFC-3168 succeeds in preserving the number of CE marks applied to a flow.  Any deficiencies we should consider are in relation to handling the distinction between ECT(1) and ECT(0), as this is what newly becomes significant with both the L4S and SCE proposals.
* For SCE to give any benefit in the presence of fragmentation, it needs 
reassembly of ECT1 fragments to be changed.
* In contrast, L4S needs no change to reassembly of ECT1 fragments, 
because it keeps to the RFC3168 transitions.  So there will never need 
to be a packet consisting of a mix of ECT0 & ECT1 fragments.

Please confirm that this is only an issue with SCE, not L4S.
And please do not cast doubt over L4S by saying this affects L4S when it 
does not.

Before going on, I understand fragmentation in both IPv4 and IPv6 is 
better to be avoided by using PMTUD. But I believe fragmentation is 
still used, particularly where an IPv4 router ignores the DF flag, which 
I believe is particularly prevalent with tunnels.

Explanation of the issue:
An SCE AQM changes some ECT0 markings to ECT1. So, when these packets 
happen to be fragments (having already been fragmented), there will 
usually be a mix of ECT1 and ECT0 fragments to be reassembled into a 
packet. RFC3168 identifies this case and explicitly says it does not 
specify what to do, which would require a new specification. So current 
behaviour will be implementation-dependent.

If fragmentation is needed, IPv6 fragments packets at source, and 
reassembles at the receiver.
So, for SCE to provide any benefit if the IPv6 source is fragmenting, 
the receiver implementation of IPv6 will need to be updated (once a spec 
has been written, agreed and approved).

Until now, I thought that, at least in QUIC, SCE would get feedback 
without changing the receiver. But, if the sender is fragmenting, the 
receiver's IPv6 layer will need to be changed as well. It's possible 
some receiver implementations might happen to do roughly the right thing 
(once we agree what the right thing is).

RFC3168 advises to set the DF flag if a mix of ECT0 and ECT1 is expected.
However, many IPv4 tunnels ignore DF and fragment anyway, using "outer 
fragments" [draft-ietf-intarea-tunnels].
Therefore, the IPv4 reassembly behaviour will need to be specified. Then 
this ECT1 reassembly during tunnel decapsulation will need to be 

As well as IP-in-IP, and IPSec, here's a list of the 14 IP-shim-(L2)-IP 
encapsulations that are widely deployed and whether they comply with 
RFC6040 (needed for SCE tunnel decap). To support SCE, they will also 
need fragment reassembly to be specified and implemented.

==Existing specs==

RFC3168 only specifies reassembly for IPv4, but explicitly not for the 
case with mixed ECT0 and ECT1 fragments. It does not seem to recognize 
that IPv6 e2e fragmentation exists, even tho IPv6 was published 3 years 

    For example, if there is a malicious or [SCE or]
    broken entity in the path at or after the fragmentation point, packet
    fragments could carry a mixture of ECT(0), ECT(1), and/or Not-ECT
    codepoints.  The reassembly specification above does not place
    requirements on reassembly of fragments in this case.  In situations
    where more precise reassembly behavior would be required, protocol
    specifications SHOULD instead specify that DF MUST be set in all
    ECN-capable packets sent by the protocol.

DF does not exist in IPv6.


Bob Briscoe                               http://bobbriscoe.net/