Re: [tcpm] AccECN field order

Bob Briscoe <> Tue, 17 November 2020 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 617933A0DC0; Mon, 16 Nov 2020 21:10:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XXRb9A3csrBz; Mon, 16 Nov 2020 21:09:57 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1D4253A0DBA; Mon, 16 Nov 2020 21:09:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=w07pg8is1Impo9my03Y+7T4BXao2ocNFqI+PQ6yIUEg=; b=cish/pjvxqn7s6RVFPCNiZi+A BPM/9ZLeAPKDPsYQHEXQPjTYGj1a5fSd+AWRJCcUwdc2TGaS1nrJ83n6TaCpXHLsOYx9rll2xROnI wRylHPGfoF6fzAYRuFLLMd1V9rdgKT3qU9YD6aLh/HoMTMfBinKICmNIP516NMIkZ3k8q5P+JMg0B 38CSt4QeWXs4JErRmdTD9iREQWo9iDp1nC0QnYevurPVWI0U1bOR+OgTorHKi6EJMWH7ZyYiTwAma J1JmA5Yt8Un9e6K5RBtG9/0qXGwi+r1JVIfNHBTzTqkuNCXw03d3Vmanzq7zQkZKB1uRcSJWeak9f mlyhUyKSQ==;
Received: from ([]:37774 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <>) id 1ketFZ-00FJeQ-G5; Tue, 17 Nov 2020 05:09:55 +0000
To: "Scharf, Michael" <>, Yoshifumi Nishida <>
Cc: Michael Tuexen <>, "" <>, Mirja Kuehlewind <>, "Scheffenegger, Richard" <>, tcpm IETF list <>
References: <> <> <> <> <> <> <> <>
From: Bob Briscoe <>
Message-ID: <>
Date: Tue, 17 Nov 2020 05:09:50 +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: <>
Content-Type: multipart/alternative; boundary="------------DD06BAC22A9BCB63AED1641A"
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [tcpm] AccECN field order
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Nov 2020 05:10:00 -0000


On 16/11/2020 17:36, Scharf, Michael wrote:
> Bob,
> One proposal using the length field with **one option codepoint only** 
> is detailed in: 
> It is the third option mentioned in this e-mail. One example would be 
> to use option length values 5/8/11 for one encoding type and option 
> length values 6/9/12 for the other encoding type (i.e., order of 
> fields). Or one could use some other combination of length values – 
> the only requirement is that a certain value for the option length is 
> only used by one of the option formats. In that approach, the value of 
> the length field would thus directly describe the encoding of the 
> option. Unless I miss something, this would work and it would just 
> require one option codepoint.
> Thus, alternatives to two option codepoints exist and I have explained 
> them on the list in March 2020.

OK, sorry, yes, I remember this now.

As I will explain in the AccECN status update talk today in virtual 
Bangkok, the draft has made provision for different length values than 
5/8/11. It says existing implementations MUST accept length values other 
than those currently defined. But then read in as many whole 3-byte 
fields as they can.

This can be used to add a flags byte on the end in future, for 
extensibility. Or any other form of extensibility the WG might decide in 
the future.

I know a flags byte at the end seems odd compared to at the beginning. 
But (if decided it's needed in future) it's reasonably easy to implement 
by reading the whole option, then processing the last byte, before 
reading the rest of the option.

I believe you will agree that this is a better way to utilize different 

And thank you for repeatedly emphasizing that you're happy with the 
2-kind scheme, or other alternatives.


> Anyway, I don’t really care how the options are encoded as long as the 
> receiver doesn’t need per-connection state for decoding a TCP option. 
> So, personally, I would be fine with using e.g. the length field as 
> described in my old e-mail. Or an additional flag byte. And one could 
> come up with further encodings, e.g., by using one or a few bits as a 
> short “type” field for each counter. This is all about protocol 
> engineering. And all these variants have their pros and cons.
> I am also fine with using two option codepoints as specified in -13; 
> this is probably the approach that consumes the least number of bits.
> Michael (w/o any hat)
> *From:* Bob Briscoe <>
> *Sent:* Monday, November 16, 2020 5:52 PM
> *To:* Yoshifumi Nishida <>
> *Cc:* Scharf, Michael <>; Michael Tuexen 
> <>;; Mirja Kuehlewind 
> <>; Scheffenegger, Richard 
> <>; tcpm IETF list <>
> *Subject:* AccECN field order
> 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 <
>     <>> 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:
>         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
>     <>
>     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.
> Bob
>     Thanks,
>     --
>     Yoshi
> -- 
> ________________________________________________________________
> Bob Briscoe

Bob Briscoe