Re: [tsvwg] SCE / L4S and fragmentation

Sebastian Moeller <moeller0@gmx.de> Mon, 16 March 2020 09:54 UTC

Return-Path: <moeller0@gmx.de>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34133A21EA for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 02:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.648
X-Spam-Level:
X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMaUkjhlYGQx for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 02:54:34 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3BE3A21E7 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 02:54:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584352465; bh=HQQAFMmBV88WBaB13lBEfNjqaLG/chwSs5dELMEdigI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=MbIAYIL2Mk0mWIE0aBD9XwUGXXGpHrjlwZ8rSsqjtEOh2vkx6V8lUZ+9QD7K/fyNE OJ+/Rqe67S0sPEQ4eyn+eQklobSqNiU4LCZk9/bjvdpc0mNEp+4jATBCAr58Zw0btd gfqiRKQL0PQNHg3JVmB9czp5af/LVPnv3bDJrJXo=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from hms-beagle2.lan ([77.10.191.105]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mof5H-1jgHiS2Ipd-00p2gf; Mon, 16 Mar 2020 10:54:25 +0100
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Sebastian Moeller <moeller0@gmx.de>
In-Reply-To: <efe9f032-b71e-2b5e-c164-7d7224c433ea@bobbriscoe.net>
Date: Mon, 16 Mar 2020 10:54:20 +0100
Cc: Jonathan Morton <chromatix99@gmail.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A6D8F974-5820-42A1-BD7D-4D27E68AC13D@gmx.de>
References: <CE03DB3D7B45C245BCA0D24327794936306F8925@MX307CL04.corp.emc.com> <2873ab79-19ad-0541-e3a4-d1d28dbc7ba0@bobbriscoe.net> <B6D58310-41E0-4172-B555-D28E7926A0B5@gmail.com> <f0a789a0-8bb8-11d9-e8f1-c0570e959151@bobbriscoe.net> <31C0056E-642C-46C0-A247-417BA16FAA3C@gmail.com> <efe9f032-b71e-2b5e-c164-7d7224c433ea@bobbriscoe.net>
To: Bob Briscoe <ietf@bobbriscoe.net>
X-Mailer: Apple Mail (2.3445.104.11)
X-Provags-ID: V03:K1:LcClS9WEEJhAcfqtNb6QXll9uCo/W7GjaQDLYS6lvkC0UXwczpj o3B5pIIGGA2EZZK3U0pr70jaowVvd2OChOpFLJfguTVO/6mPUU+ihc26sCAkZPfLK3TaBt/ zlQwdUCd74asw/yUA14OUWzUpb+P7RZmo/BwIckkYQNwIeyGpV29af7+6brwjrRtJ13zOQ0 IbOL3MslpDYYfxEXHOpMQ==
X-UI-Out-Filterresults: notjunk:1;V03:K0:u8yoTHcZ4hY=:r9M0TMBdegMgX3q1eh3xMx a50eHC9f1VqmwvFL+wgen/90m9GfjgZRiPrMcw5xEyr2wdbmLQ4SV2OaaUWqh8JPZ+oj4pkRU skj0C+qkxp+0V2162QVC7S5ECnfbuQ0ZoE8pMffobaAWwU+NAjvdS1NtMhFHafj04Limz80TN QTKRNvwIZp408te1w4Mjy7m38d7DH/V7Z30ZK+4062YL6J2yyMTOeXSU2/K8RaXrGlhJQjbyr jqSavQYGO/8ylMmWCdzJR8xboz3KUUl664XGo76iA9C25LPexfnw0+h86fgb3hzfUO6yEmIcE b8/BR0j5icUwxJmmkx5oeZTKCG61MIuXP/Ir32CyLZQ/q3B8OvrJHPFk0RD9w0PiAi5baYTZx gMGfigST9knnC/ZntAQXJWA0nOgVgXsW1/HNeVrZNt1Yo4JiqZPlMtFjs2fdR9uML/TDW7EGU cb4tFcToTw1YOwpg0Oqv8uTtHI8XlakY6BTUJRMYT6ADkVNdzqvHGwBImJriqKCyYS8T+3Pky PUatfOmFeXXhvtPSwZHZunsm4RRsAAj1JwNZl+aufiJEnawQKwDqmoULtyhNPRDttMoDoSTv+ mp9whguQFj7clmR6mKd8CpIe4z8YOSi4tsUnQC48xFoOrtcEnGh8B8LdZ7wtvAQbtGtryvu8l ri+rukj/nwGQyLtKVGHDsA41nINYZKHf+WVk2NlCB73WDGY+QalFaLYJe5bc/834hV7GoWQdn SDCbwGeQ+1zWN/Ofe/sqGl1nQ4VPbxFGdo0sqJwQ99qsyIglEzNmQC2QJqBOqZaw3dTP8/oWp 4fOVhRZvaalnxx/e5L8qn4QCyzN4KkkaWCdLUID5/Y4Nmf/TV80BTeUMo9ce/PZmvlRKJoT7U HqDPDQOI1Y3yBFpA4n0deBInPq1/oTpemdW1rVeb7HfHrCVSFbLsNsutyiAKcmgG+jDfQcVIo moooDbKeFE8bsrz9moBrjyg4kQqbOuzPhToX34S6VryD0wEtdXlMTYGfgDE7XF3pmpD93Fs9W I9fLOhX+/D6sJGPPAm9ZOk2CzqKHojL163JOW0e0PRPV7yAs22MnONkFYLg8N6iM4ZwKS8MmI B21UmNDOI1MzLf9Tf5Z1EayTVc48ll8JI8N9oob0+O+LrtAv6R06qPbJcjhPlWTvlKT7ulB9J aav/5CxBcIBXBY/LKwNZ/pjIBt0DAJrMAlOMPoEmx3nrnHo9+wVbrWXn0bGLZdH91pXtVTApt xLcBWeLF4bua210RU
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/m6JebXmolUDehVIZDR-xOw0RMJk>
Subject: Re: [tsvwg] SCE / L4S and fragmentation
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: Mon, 16 Mar 2020 09:54:36 -0000

Dear Bob, dear list,

I think it is time for us to take a deep breath, a step back and to not assign to malice what can be equally explained by simple misunderstanding(s). I believe this discussion while heated at times is done in good faith by all parties, and it does not encourage the quality and civility of the discourse to try to assign a bad faith effort to the respective other side. So how about we (including myself here) try harder to be nicer to each other even while discussing wildly different positions.

I will add nothing material to the discussion here, since this is about improving the tone...

Best Regards
	Sebastian



> On Mar 15, 2020, at 14:28, Bob Briscoe <ietf@bobbriscoe.net> wrote:
> 
> tsvwg,
> 
> I would like to draw the list's attention to this email, which is a classic example of the way Jonathan Morton spins untrue FUD (fear uncertainty and doubt) over L4S, even when the failure mode under discussion is actually a downside of SCE, which L4S was deliberately designed to avoid. 
> 
> 
> Whatever,... now to you Jonathan,
> 
> It's hardly necessary to be so underhand. Even without fragmentation, SCE markings applied within a tunnel usually won't reach the receiver anyway, as I've explained elsewhere. So in the sub-case of fragmentation, if SCE markings also don't survive reassembly, SCE-in-a-tunnel is just something that was already broken, getting broken again.
> 
> 
> inline...
> 
> On 13/03/2020 21:22, Jonathan Morton wrote:
>>>> [JM] 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.
>>>> 
>>> [BB]
>>> * 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.
>>> 
>> [JM] I'll agree with this: where the ECN codepoint is set at origin (or, equivalently, before the fragmentation point), the fragments will all carry identical codepoints and will be reassembled correctly under RFC-3168 rules.  These rules also handle the case of CE marks being set on IP fragments on the tunnel path.  The case of marking with ECT(1) is indeed left undefined, which is undesirable.
> 
> [BB] You rewrite my description of a downside of SCE in woffle-language that pads out the scenarios with irrelevant cases and obfuscates by removing all mention of the words SCE or L4S. Then you snip (reinstated below) where I asked you to retract your untrue assertion that L4S suffers from this as well. 
> 
>> 
>>> [BB] 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.
>> 
> [BB] I just knew you were going to snip this. You're so predictable.
> 
> Moving on...
> 
>> 
>>> 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.
>>> 
>>> DF does not exist in IPv6.
>>> 
>> [JM] I think it would be more accurate to say that IPv6 behaves as though DF is *always* set.  There is no defined mechanism for a router to perform fragmentation.  Fragmented packets may be generated *at source* to eg. convey an oversize datagram; TCP would just reduce the MSS to fit, when notified of a reduced MTU on the path.  So I don't consider IPv6 fragmentation to be a significant problem.
> 
> [BB] You've conveniently side-stepped oversize UDP datagrams over IPv6, where the IPv6 source has to do the fragmentation, and IPv6 reassembly logic at the destination would need new logic to propagate the SCE markings.
> 
> I drew attention to this in the IPv6 section of the email below (which you didn't respond to).
> 
>> 
>> Of course, you could end up tunnelling IPv6 packets through a fragmented IPv4 scheme.  But that mathematically reduces to the existing problem of fragmenting IPv4.
>> 
>> 
>>> 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.
>>> 
>>> IPv6:
>>> 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).
>>> 
> 
> [BB] 
> QUIC: https://tools.ietf.org/html/draft-ietf-quic-transport-27#section-14.1 recommends (but does not mandate) that QUIC implementations clamp the max datagram size. Ideally it recommends using PLPMTUD as well. 
> 
> The latest draft on RTP feedback over UDP mentions MTU issues but is not as concrete as QUIC:
> https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message
> 
>>> 
>>> IPv4:
>>> 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 implemented.
>>> 
>> ISTR, at some point in the past, interim language was suggested which would require taking the ECN codepoint from one of the fragments constituting the packet, with the behaviour being otherwise unspecified except by the existing rules.  This would be a worthwhile improvement from SCE's point of view, and is likely to match at least some existing implementations.
> 
> [BB] The language was in the previous revision:
> https://tools.ietf.org/html/draft-ietf-tsvwg-rfc6040update-shim-09#section-5
> 
> It was for PCN (pre-congestion notification), which is a standards track set of IETF RFCs that were implemented but not deployed, AFAICT. I removed all that text because you objected to the same language for CE. I generalized it into a requirement to achieve an externally observable effect, rather than saying how to do it.
> 
> I would be happy to reinstate it. But you can't have it both ways: you want standards track RFCs to cater for SCE, which isn't even chartered IETF work, but not to cater for other standards track RFCs.
> 
> You do not seem to be aware of the other WGs and other standards bodies (3GPP, IEEE802.1) that have been involved in this draft, and who are waiting for it to go to RFC (including an RFC being held in the RFC Editor's queue).
> 
>> 
>> An implementation which performs a bitwise-OR across the ECN fields of the fragments would effectively convert partial SCE marks into CE marks (as the ECT codepoints are 01 and 10).  This is less than ideal, but at least some form of congestion control is maintained by this.
>> 
> 
> [BB] We're talking about a standards track RFC-to-be here. You're asking for it to includes requirements to support SCE that isn't even chartered IETF work. If you want the IETF to give a signal to implementers of large numbers of existing layering protocols to update their code for you, you have to do a lot of work convincing people first.
> 
>> 
>> RFC-3168's existing recommendation to set DF seems like a good one to me, and is effectively automatic with IPv6.  Tunnels which perform outer fragmentation should be fixed to implement MTU Discovery support instead.  That seems like the easiest fix to me.
>> 
> [BB] If you mean MTU Discovery between the tunnel endpoints, that doesn't help when a packet arrives that is too large for the discovered MTU. So you must mean supporting MTU Discovery by the endpoints (by the tunnel ingress sending a PTB ICMP). But most networks black-hole these nowadays. 
> 
> So I can only conclude that you're masquerading as an expert again, and we should just move on. I wouldn't mind if you couched your objections with "I'm not sure but,..." or whatever.  
> 
> Anyway, this is not how IETF RFCs work. They have to specify what to implement, in order to interoperate with what exists. Not what implementers and operators should have done. The only grey area is when what exists is non-compliant. But if non-compliance is widespread, it has to be catered for.
> 
>> 
>>> 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.
>>> 
>> The list of 14 appears to be missing.
> 
> [BB] Sorry [got distracted]:
> https://datatracker.ietf.org/meeting/101/materials/slides-101-tsvwg-sessb-35-ecn-transport-00#page=4
> 
> 
> Bob
> 
>> 
>> - Jonathan Morton
>> 
>> 
> 
> -- 
> ________________________________________________________________
> Bob Briscoe                               
> http://bobbriscoe.net/