Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?

Bob Briscoe <ietf@bobbriscoe.net> Wed, 13 November 2019 13:30 UTC

Return-Path: <ietf@bobbriscoe.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE9712025D for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 05:30:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MP49Hxbo343U for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 05:30:25 -0800 (PST)
Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 CDA14120804 for <tcpm@ietf.org>; Wed, 13 Nov 2019 05:30:24 -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:From:Cc:References: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=PkLy7/4k27pdxJyA1d0TbfFU8OZETHOSvXvdsJxB6BI=; b=KbapFgv0W+uFPqUWDag6aiXm2 f5KGp3HgyZQp/Awk+NW/GXvI0ilBZTfNHjxZcVVIiIff+h93or/DrAB0eL9x9oib2qa+eRhsOUyfR ltbLHSI6LM/1/QaAQPEghsbJ0/hlguy7s3G+TwtbgKWPLqt2M/Dh9XIijyQcacdPpsLXBpZ+mxNbw 4K5wCba/gHRJRzwFTU50Y9shl8MqtyhakJIvtkEdyc1dnb9hkGjssyEYLrO1PadQZLDrGyo4HvWcU CPhBKrSliS/GmQfcWKDmintclERMasCFu1MBupsKDKfhVlVcYu1PdCsIM0r/gCNuu9GHLTx0TLxy3 ss2WlVhxQ==;
Received: from [31.185.128.31] (port=50426 helo=[192.168.0.5]) by server.dnsblock1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <ietf@bobbriscoe.net>) id 1iUsj0-0003p6-Ru; Wed, 13 Nov 2019 13:30:23 +0000
To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
References: <CADVnQykh-MjnfzNtRQ22fwxUS3BY_YOJOPghV9B08s+dN9G17Q@mail.gmail.com> <D2172685-A0C0-4CF5-9B1F-4BD07B5DCC63@ericsson.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
Message-ID: <06e2790a-def0-c28a-fc0d-f3a897d5bc49@bobbriscoe.net>
Date: Wed, 13 Nov 2019 13:30:22 +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: <D2172685-A0C0-4CF5-9B1F-4BD07B5DCC63@ericsson.com>
Content-Type: multipart/alternative; boundary="------------2A4B8AB4014576494A892F08"
Content-Language: en-GB
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.dnsblock1.com
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: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/EPd0_4acNXhRjwCGIO1oRcstSho>
Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
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: Wed, 13 Nov 2019 13:30:28 -0000

Neal,

Rather than the IETF have to decide up front which ECT value will be 
more prevalent, I did suggest the following mechanism to my co-authors. 
However, even tho it's fairly simple, we decided wasting some space was 
simpler.

Given TCP Option space is in short supply, if the WG prefers, we can 
include that idea in the spec:...

The data sender for each half-connection currently initializes

	r.e0b = 1 and r.ceb = r.e1b.= 0

then communicates these to the other end in the option. We could make 
the initial values into a signal that determines whether ECT1 feedback 
comes first for feedback on that half connection. For example:

	r.e0b = 0 and r.ceb = r.e1b.= 1

could mean ECT0 & ECT1 will be the other way round.


Bob

On 12/11/2019 16:09, Mirja Kuehlewind wrote:
> Hi Neal,
>
> that's a good point. The order of the field was based on what is expected to be the most likely case. Currently most traffic, if it uses ECN at all, will set the codepoint to ECT(0). With deployment of L4S this could change in future, however, there are also still ways to extend the negotiation in the AccECN TCP handshake to e.g. support this case better in future.
>
> Mirja
>
>
>
> On 11.11.19, 18:25, "tcpm on behalf of Neal Cardwell" <tcpm-bounces@ietf.org on behalf of ncardwell=40google.com@dmarc.ietf.org> wrote:
>
>      A particular question in regards to the AccECN option:
>      
>        https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-09#section-3.2.6
>      
>      The AccECN option spec lists the EE0B field first, with the EE1B field
>      at the end.
>      
>      Given that L4S plans on using ECT(1) for data packets, and unchanging
>      counter values can be omitted from the end of the AccECN option, why
>      not list EE1B first, and EE0B last? With EE1B first and EE0B last it
>      seems that in the common case for an L4S connection the (unchanged)
>      EE0B could be omitted, allowing 4 extra bytes of payload per packet.
>      AFAICT this extra 4 bytes would increase goodput for applications
>      using IPv4 or IPv6 with an MTU of 1500 by about 0.3%, by my
>      back-of-the-envelope calculations.
>      
>      best,
>      neal
>      
>      _______________________________________________
>      tcpm mailing list
>      tcpm@ietf.org
>      https://www.ietf.org/mailman/listinfo/tcpm
>      
>

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