[tcpm] AccECN field order

Bob Briscoe <ietf@bobbriscoe.net> Mon, 16 November 2020 16:52 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 3ABC53A13AA; Mon, 16 Nov 2020 08:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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_PASS=-0.001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 1C53RZd0AeE6; Mon, 16 Nov 2020 08:52:20 -0800 (PST)
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 A12A03A12B4; Mon, 16 Nov 2020 08:51:45 -0800 (PST)
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:References:Cc:To:Subject:From: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=F0qtAn67cI8O90fPtt7aTqSVvKVqLldN5g1GR0Bpl4o=; b=H05hHDeIzBJGFmTX0jKNq/KAn ftkr4Q9dkenKR7rKK3E07AK9/XcYco32fdyyYYFaqxPSf5Y3Mgm2gO94rMRC3SxALq0D7WxGMtxVm sNT2AmLGmIo0qtAWsHofhmiij9ZV6bpxXICLhQGtbN3443PTIX9k0TCxSLGb1UmuXwUQbyh5bhtBw /3gSB2KqfN7FC7kGlDmTHGoK3VSXAa6/XHivx0qkfyNyXeNf/Nh1qnm/0PyfE3n2wPypfiAoZ0V7C pziRpzmCeXo9UVTq0qWM2pDrnwOueXCdpHp3KNfBejTGErD0kHflNagr+GuqkL4eOGm+Pi9rEGdzX pp/yzC/EQ==;
Received: from ([]:34130 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 1kehjD-006mH3-9D; Mon, 16 Nov 2020 16:51:44 +0000
From: Bob Briscoe <ietf@bobbriscoe.net>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: "Scharf, Michael" <michael.scharf@hs-esslingen.de>, Michael Tuexen <tuexen@fh-muenster.de>, "tcpm-chairs@ietf.org" <tcpm-chairs@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, "Scheffenegger, Richard" <Richard.Scheffenegger@netapp.com>, tcpm IETF list <tcpm@ietf.org>
References: <42eee5b7-fc0d-9576-c2ab-128706611a96@bobbriscoe.net> <bca1931d-b99e-447d-2ccc-8f13969df7f4@bobbriscoe.net> <CAAK044S8rVVRHjkHBxCfGDD6tOTRJvnsVOt3eGf0z95N0o=mDQ@mail.gmail.com> <CAAK044QRYKmk9GbPn1N-TxAr5E7TDr87mV3UJJuY2FNNKyd_Jw@mail.gmail.com> <279fb3d5-0000-f704-d88f-08ab0fa9e83a@bobbriscoe.net> <CAAK044TtbFWjb-msj3rA6vE+ZB99O1qAwhUFwzD2+rehzX9a7Q@mail.gmail.com>
Message-ID: <9bdf71e9-4af0-f5ee-f2f7-e63349956500@bobbriscoe.net>
Date: Mon, 16 Nov 2020 16:51:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <CAAK044TtbFWjb-msj3rA6vE+ZB99O1qAwhUFwzD2+rehzX9a7Q@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------0705A85F7D664DA337EE6B85"
Content-Language: en-GB
X-OutGoing-Spam-Status: No, score=-1.0
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/tcpm/nAWaKzElYD94TrlbeV-QYvFpIIs>
Subject: [tcpm] AccECN field order
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Nov 2020 16:52:27 -0000

Yoshi, (adding the tcpm list in cc)

On 05/11/2020 06:58, Yoshifumi Nishida wrote:
> Hi Bob,
> On Wed, Nov 4, 2020 at 3:29 PM Bob Briscoe <ietf@bobbriscoe.net 
> <mailto:ietf@bobbriscoe.net>> wrote:
>     Yoshi,
>     On 04/11/2020 06:51, Yoshifumi Nishida wrote:
>>     Hi, folks,

>>     In my understanding, I'm not sure if we settled down on using two
>>     option kinds or encoding schemes for 24bits fields in acc ecn draft.
>>     So, I think there're still something to be clarified and hope
>>     things will be settled at the meeting.
>     [BB] I know a WG can change it's mind at any time. But I'd rather
>     we just clarified what a previous decision was, to avoid the need
>     to keep re-opening discussion on a question that have been decided
>     then changed three different ways already.
>     My memory is not so good these days. I trusted that Michael S
>     remembered the decision correctly, and I seem to remember that
>     decision being made.
>     I've just checked the minutes of the last interim:
>     https://datatracker.ietf.org/doc/minutes-interim-2020-tcpm-01-202004291600/
>     and they mention Michael's proposal to use two kinds, but don't
>     record any decision.
>     The jabber log gives no clues about any decision.
>     I can't find an audio or video recording. Can you point me at one?
> I thought that it's because there was no clear decision at the meeting.
> But, you can check https://www.youtube.com/watch?v=KsB0_Nb8-kA
> Please let us know if you have any questions or opinions with regard 
> to this.

[BB] I checked the Youtube link you sent below.

First I think we're agreed no-one was fighting for us to keep the 
previous way we did this (using the initial value of the field to set 
the order for the connection).
In my presentation I said there was strong resistance from Michael to do 
it a different way.
(also, offlist, the co-authors including me also didn't like this so 
much. And Ilpo said it made the implementation complex.)

Then came the question of what we do instead. There were three 
alternative proposals:
a) use 2 option kinds
b) add a flags byte
c) somehow use the length field maybe

Michael raised (c) in the meeting as a possibility, but no-one could 
think how to distinguish two options of the same length but a different 
field order using the length field. Michael said he'd post any ideas to 
the list if he could think of any, but that didn't happen.

So we're left choosing between (a) and (b).
I said in the meeting (and on the list when discussing with Ilpo) that 
I'd be happy to go with (b), but only if there was another use for a 
flag. Because it would consume 1B more options space in many packets, 
which is a scarce resource.

Ilpo had a proposed use for another flag (to help synch counters after a 
loss), but I think the discussion about it ended that it wouldn't be 
helpful, 'cos the way it worked depended on itself (circular logic).

In conclusion, I don't think there was an explicit decision to go with 2 
option kinds, but it ended up as the 'last person standing'.
I like it. It's simple. And apparently option kinds are not such a 
scarce resource.

Perhaps we can ratify this in the WG tomorrow.


> Thanks,
> --
> Yoshi

Bob Briscoehttp://bobbriscoe.net/