IETF Logo Mail Archive

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

"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Wed, 13 November 2019 16:30 UTC

Return-Path: <Michael.Scharf@hs-esslingen.de>
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 1B8641208E3 for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 08:30:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 LsvihRnjHnU1 for <tcpm@ietfa.amsl.com>; Wed, 13 Nov 2019 08:30:05 -0800 (PST)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FB812088A for <tcpm@ietf.org>; Wed, 13 Nov 2019 08:30:04 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id 2EA1A25A1A; Wed, 13 Nov 2019 17:30:03 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1573662603; bh=IMm5KkJ4CHDKyuhK93TpOULPjzOl5dCMh5F+3iubtks=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=lHUo7Vp/UjNJNWkTnseeexQzINdW1Cx2KwPpvZ/3WuPK0oAf7pvxqETHRD6yyyHK+ 3qOUYm4AmTiN2qedhrDkNV6HB5/XGnAUWmY1dOg9LTYjBO9i5pf+3PElG4xsO2xQHN vHDsTTVwBhMez7iyWdgGeVrotSC0CgOTtsKXhAQQ=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbqVESMQP7LG; Wed, 13 Nov 2019 17:29:59 +0100 (CET)
Received: from rznt8102.rznt.rzdir.fht-esslingen.de (rznt8102.rznt.rzdir.fht-esslingen.de [134.108.29.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Wed, 13 Nov 2019 17:29:59 +0100 (CET)
Received: from RZNT8114.rznt.rzdir.fht-esslingen.de ([169.254.3.61]) by rznt8102.rznt.rzdir.fht-esslingen.de ([fe80::f977:d5e6:6b09:56ac%10]) with mapi id 14.03.0468.000; Wed, 13 Nov 2019 17:29:59 +0100
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: Bob Briscoe <research@bobbriscoe.net>
Thread-Topic: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not EE1B first?
Thread-Index: AQHVmLUL8707rVPe1ES9nrAQ4+JPDKeHpN6AgAGnlyA=
Date: Wed, 13 Nov 2019 16:29:59 +0000
Message-ID: <6EC6417807D9754DA64F3087E2E2E03E2D501415@rznt8114.rznt.rzdir.fht-esslingen.de>
References: <CADVnQykh-MjnfzNtRQ22fwxUS3BY_YOJOPghV9B08s+dN9G17Q@mail.gmail.com> <D2172685-A0C0-4CF5-9B1F-4BD07B5DCC63@ericsson.com>
In-Reply-To: <D2172685-A0C0-4CF5-9B1F-4BD07B5DCC63@ericsson.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.48.164]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/ImHKpqSxpJkvkg6j3LGkbzt-n4k>
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 16:30:07 -0000

Wouldn't it make sense to work through that now if this gives a real-world benefit?

While AccECN is indeed extensible and this is documented in the document (thanks!), as far as I understand there is only so much one can do with few bits. At least to me it would be more convincing to understand now how this use case could be solved, in order to ensure that there are no open issues in whatever the initial spec describes.

Michael (with no hat)


> -----Original Message-----
> From: tcpm <tcpm-bounces@ietf.org> On Behalf Of Mirja Kuehlewind
> Sent: Tuesday, November 12, 2019 5:09 PM
> To: Neal Cardwell <ncardwell=40google.com@dmarc.ietf.org>; tcpm@ietf.org
> Cc: Bob Briscoe <research@bobbriscoe.net>
> Subject: Re: [tcpm] draft-ietf-tcpm-accurate-ecn-09: AccECN option: why not
> EE1B first?
> 
> 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
> 
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email