[tcpm] Partial implementation of AccECN Option logic

Bob Briscoe <ietf@bobbriscoe.net> Wed, 06 July 2022 14:57 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 303D9C159487 for <tcpm@ietfa.amsl.com>; Wed, 6 Jul 2022 07:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.104
X-Spam-Status: No, score=-2.104 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 pJqX446rgdaF for <tcpm@ietfa.amsl.com>; Wed, 6 Jul 2022 07:57:01 -0700 (PDT)
Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu []) (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 39610C157B54 for <tcpm@ietf.org>; Wed, 6 Jul 2022 07:56:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Subject:From:To:MIME-Version:Date:Message-ID: Content-Type:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=knltG6tLFhnyiOEg+bijzfIbBBA09GXAMLm58EDoWKg=; b=AnFIIrm2vlzRWOpZ2V0eA0HA2N GjYSe4dQmvTiOENAsFDn52SJ04jyGJY5h2HB5xF6hvDVeQNSzqnDtAnRt3UUE56cm4tLe4CZ5GDLs zms+HG9Y7vI9r5Nw9i5UCVXCTZzVzKG1fsvMsMStmnSTakQRdupgTjxSRWfLl9a7dbnCEBPPxWkRp gCbIOanwIpbw7uPSCqWRiM4Yaf+GGdgHmMd71rCnwJnPpv+SbGULDWHOpFo8YnN4fGPSztpDtiG+f aPqrkB/pDLnPqPEfUJbZyRcOSDPH3ZtyWyPT7rz5xQWXmPWYHvQHJvcS8TAXTZtYkjDgP2tRDTPK3 ccsJLrrQ==;
Received: from ([]:50724 helo=[]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from <ietf@bobbriscoe.net>) id 1o96Sd-0003Dt-SI; Wed, 06 Jul 2022 15:56:59 +0100
Content-Type: multipart/alternative; boundary="------------uH00rWi0W7doqxsxMQdjdbiH"
Message-ID: <5fd201f8-5457-3184-302d-c2f653564647@bobbriscoe.net>
Date: Wed, 06 Jul 2022 15:56:57 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-GB
To: tcpm IETF list <tcpm@ietf.org>, Yoshifumi Nishida <nsd.ietf@gmail.com>
From: Bob Briscoe <ietf@bobbriscoe.net>
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu
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: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net
X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0uJumvVAu4i88fmbT7wKlrpP5B0>
Subject: [tcpm] Partial implementation of AccECN Option logic
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.39
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, 06 Jul 2022 14:57:06 -0000

Yoshi (and tcpm)

Thanks for reminding me to get the AccECN draft finalized.

In the last tcpm meeting, I listed two things we're still planning to 
I'll deal with each in a separate email:

This email is about switching round the recommendation on what is 'least 
worst' to leave out of an initial implementation in §3.2.3:
as below.


    Even if a developer does not implement sending of the AccECN Option,
    it is
    RECOMMENDED that they still implement logic to receive and
    understand any
    AccECN Options sent by remote peers.


    Even if a developer does not implement *logic to understand
    received* AccECN
    Option*s*, it is RECOMMENDED that they still implement logic to send
    Options *to provide richer feedback to those* remote peers *that do
    understand it.
    The logic to send AccECN Options is the simpler to implement of the
    two sides.

Question for the list: Ought this to be a MUST, rather than just 
If there's disagreement, we won't make it a MUST.

Rationale for the change: After Ilpo implemented the AccECN Option, he 
told me:
* the logic to receive an AccECN Option was more tricky, because it 
includes heuristics to estimate the counters if ACKs arrive without the 
* whereas the logic to send them was fairly straightforward (now that 
the recommended default option size is constant). It essentially 
involves implementing:
    - the byte counters,
    - choosing the field order,
    - building and sending the option fields,
    - checking whether sending the option puts the connection into a 
black hole (and optionally caching this knowledge).


Bob Briscoehttp://bobbriscoe.net/