Re: [tsvwg] Status of ECN encapsulation drafts (i.e., stuck)

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

Return-Path: <ietf@bobbriscoe.net>
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 549D43A0DF5 for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 09:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level:
X-Spam-Status: No, score=-2.088 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, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.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 xjvhHSwlZEpx for <tsvwg@ietfa.amsl.com>; Fri, 13 Mar 2020 09:42:08 -0700 (PDT)
Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 321723A0F15 for <tsvwg@ietf.org>; Fri, 13 Mar 2020 09:42:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To: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=T8LXcS8/f5n63obCW7Q5M1/JhqrwWo1bTVXDajDca2c=; b=3eS9DEkD4le4UoxkyDOy8woCQB wbnttpQE6a//sziKz5/sJmm3U9QuIeDPsebfvLYViB294q2DbDcQAaF3DCytFk2/13R5obPEg285M v/Eos1jY0Zgy3n0WnyI9VJvcuUZn7qe47hhWsmY5hTgL8z5rquxCQ4eU6qZ3UMr8mf+UkYfOyZPJB eLfNEM/masbQICDnBdjrg1mdhIcwfTrpf4foO/R+rqdOjQ9gZ2UpDWLQKowKxIGMSKPM10E/yd5td TG+SoojNDD68dDHJosdaIgwCs0yY4UysaU1gVQXl1kvthn/KmbqiREXUu8WZczAwySDT9vGU94Rch qOaktL5w==;
Received: from [31.185.135.141] (port=39046 helo=[192.168.0.4]) 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 1jCnNt-00FI83-7j; Fri, 13 Mar 2020 16:42:05 +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> <3ee6e427-9dc9-e885-21a9-df9e35d99006@bobbriscoe.net> <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <5d8f11f3-9def-14b1-4923-4eb02caf51eb@bobbriscoe.net>
Date: Fri, 13 Mar 2020 16:42:04 +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: <C1696430-D2D2-48BB-AB17-EFB77EE474DE@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/E4pp3g62GTYN8dKU65odx0pDQB0>
Subject: Re: [tsvwg] 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 16:42:14 -0000

Jonathan,

On 13/03/2020 14:03, Jonathan Morton wrote:
>> On 13 Mar, 2020, at 3:03 pm, Bob Briscoe <ietf@bobbriscoe.net> wrote:
>>
>> Specific problem: End-to-end, taking into account both fragmentation and reassembly, the "logical OR" reassembly process required in RFC3168 roughly doubles boththe number and the proportion of CE marked packets and the number and proportion of CE-marked bytes (relative to a parallel flow with slightly smaller packets that is not fragmented).
> Before I attempt to address your arguments in detail, I want to clarify something fundamental.  I think this may be one good reason why David Black wants to separate the concerns of reassembly (covered by RFC-3168) and decapsulation (covered by RFC-6040) - a sentiment I completely agree with.
Yup. As I said in that conversation, that's not in question.
>
> Let's consider two original, consecutive IP packets: A B.  They are encapsulated by a tunnel, producing TA TB.  These are both larger than the MTU, so are fragmented into TA1 TA2 TB1 TB2.  On the tunnel path, an AQM applies a CE mark to TB1.  Eventually these packets are decapsulated, prior to which they must be reassembled, and the CE mark must be preserved somehow.
>
> What you seem to imply is that somehow, TA2 and TB1 can be reassembled into one CE-marked packet, leaving TA1 and TB2 separate, and that decapsulation may then apply the CE mark to both A and B.
Eh? Where do you think I've implied that? Nah.

I've just re-read, and maybe you've assumed that the single counter 
implies I'm just reassembling any fragment with any other. No. Obviously 
it only reassembles the fragments of one packet back together. I didn't 
think I'd have to say that!

Anyway, the implementation is only an example for people who find it 
easier to understand something concrete - the point is about the 
requirement, not how to implement it.

Nonetheless, just in case, I ought to say what does /not/ happen in the 
example implementation: A non-CE fragment arriving to be reassembled 
cannot cause the reassembled packet to be CE-marked. So there is no need 
to check the counter unless an arriving fragment is CE-marked. Also, 
regarding complexity, I've realized that both the "logical OR" and the 
"CE-byte-preserving" algorithms require per packet state (whether the 
re-assembled packet will be CE marked). The CE-byte-preserving algo adds 
one counter per-interface (probably two counters in practice, so writing 
by the incoming and outgoing processes can be decoupled).

>
> But this does not jive with what I know about IP-layer fragmentation, in which TA1(ECT) TA2(ECT) always reassembles into TA(ECT), and TB1(CE) TB2(ECT) reassembles into TB, which is then CE marked by the RFC-3168 bitwise-OR rule.  We would then have A(ECT) and B(CE) transmitted onward, which seems to match the intent of the AQM - in particular, the number of CE marks is preserved, not doubled.
>
> What am I missing from the context of your objections?
Well, I don't know, 'cos I don't know how you came to that 
interpretation (you'll need to point to the sentence that made you think 
that, if it's still not clear).


Bob
>
>   - Jonathan Morton

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/