[tsvwg] Re: TSVWG Adoption Call for draft-duke-tsvwg-udp-ecn-03 as Informational, ending on 29th November 2024

Martin Duke <martin.h.duke@gmail.com> Thu, 19 December 2024 20:20 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FA1C1840ED for <tsvwg@ietfa.amsl.com>; Thu, 19 Dec 2024 12:20:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyGQzyTzBIi8 for <tsvwg@ietfa.amsl.com>; Thu, 19 Dec 2024 12:20:25 -0800 (PST)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86298C1840C1 for <tsvwg@ietf.org>; Thu, 19 Dec 2024 12:20:25 -0800 (PST)
Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-5174db4e34eso1316961e0c.0 for <tsvwg@ietf.org>; Thu, 19 Dec 2024 12:20:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734639624; x=1735244424; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=7L95fQHttcc/k1FBdCpZQVfvyCPEURQN8E3Lt+uIEvQ=; b=dz0q8yCcf3f790A/oNH65CupxReKQq7eAJW3pnyBbyLMarKpVJCRiRstZ93HWxUT9j qBiVyIE805QbiX2aoTGVIaXqC7XURVRcBtZbI5EaQI7zR5T4/f6zvR3uCtIxxwfx78hX 7epgJ5+HgugxoINgu28///odYNO8RobvzYnHLs3VJBBcn1P9FDRYKMiNu8pjVdKxzBZ+ J7m4so5aoi5BgizbR+tWyJFUCxc0tQ7DTbkr9/r9pB/otx8xW9kbFRnZCMgyej0DWEes 44WJNVHPF6C49UzCUnhcGz/7wdssudZwxa0m1Mgp22LwsPwkGm/vDyjJIbXIH3ZL1GBI IGLg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734639624; x=1735244424; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=7L95fQHttcc/k1FBdCpZQVfvyCPEURQN8E3Lt+uIEvQ=; b=sUbTQfCb9F3tROCwPdEVgc+fiD0jXIhhB88SgsNQgCVa2ca8SyreuC5tu72aFcB1V5 WKVcRrsz7CxUmyHYnANTD2KR1f4C/zqVMZgFuiNQ4dbdHMOLW3+diU7HmuKdAM/ZByGm SOHe6Eb1XZgpBL7nBsNSR6EoEn1hg/sZdPzOkn3Ec+HzsbEs8o+tCFA1SfpJixWPsQp0 JqPon8jwxd/Idq9G4YOJiTqt6h4s19N7z4zS5k8GFJP4MumrK+RR4Ie5mF5yf3mBG09l Ta2+jWg1pDM+osVaODJBywlBp7VcV20+Su2ki+NjugmzRe23e94DmDQvX1sYA6cuDTmG IfCw==
X-Forwarded-Encrypted: i=1; AJvYcCXb42lM9he81oBOgeC+uJYb8KTiHqCXXXKqriJKHiwPlmfYnY2mvCzRP8sNuRvlO5aNxREfXw==@ietf.org
X-Gm-Message-State: AOJu0Yzs9tDS6UQtc0nVR2Wqt+nAyVLk4AmUg0ib5WYf+k0axteyeO7y gBULj6OZT5x8AsjqmXCbQFH8GXKzftK550IihfO9Q11J5s29INerzd/r6mZJjhzI1R+itUHj44s 12mewnSeGvX/OihAGmEAzIQyjhpA=
X-Gm-Gg: ASbGncswM+pyF5nr9HDa8iTe5Q4axL9AESeq+bfkuUhkr9TlTY9ADS8Jf25V8s9fKrp O1oyjT8xO7C6JsjasBhkFp0h/ME800Xk6mE1J/JF8nP4uAJZaVLLHMLpLhT7wlsIBQjZz
X-Google-Smtp-Source: AGHT+IH3A6U/WB07awfNJ/j6Y2HGQhjgvpey8TBv7OehOkRTJPRqzfsuwEMXwZGREf/lDXL/keBvtWwa7S9d1GUygzk=
X-Received: by 2002:a05:6122:438c:b0:515:25f5:46f6 with SMTP id 71dfb90a1353d-51b64bc8eedmr4799154e0c.4.1734639624553; Thu, 19 Dec 2024 12:20:24 -0800 (PST)
MIME-Version: 1.0
References: <91c89e4a-834e-4450-bcf8-ecc5fc8b7f03@erg.abdn.ac.uk> <7FCABB1F-1B88-4303-804C-29615B96A162@CableLabs.com>
In-Reply-To: <7FCABB1F-1B88-4303-804C-29615B96A162@CableLabs.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 19 Dec 2024 12:20:12 -0800
Message-ID: <CAM4esxRYj9z6MoFM7reb36YxXq3GDw8AL-3zT0qJkfPNqBwX-A@mail.gmail.com>
To: Greg White <g.white=40CableLabs.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a28e5f0629a542f0"
Message-ID-Hash: PFDEF3WB3T6H65LUNUJVRBFZ2O77VT2S
X-Message-ID-Hash: PFDEF3WB3T6H65LUNUJVRBFZ2O77VT2S
X-MailFrom: martin.h.duke@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tsvwg.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, "tsvwg@ietf.org" <tsvwg@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [tsvwg] Re: TSVWG Adoption Call for draft-duke-tsvwg-udp-ecn-03 as Informational, ending on 29th November 2024
List-Id: Transport Area Working Group <tsvwg.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/t2GFruRYV6X-aWNr8TY6C609klE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Owner: <mailto:tsvwg-owner@ietf.org>
List-Post: <mailto:tsvwg@ietf.org>
List-Subscribe: <mailto:tsvwg-join@ietf.org>
List-Unsubscribe: <mailto:tsvwg-leave@ietf.org>

thanks Greg,

I've put your terminology change in Issue #15.

I'm disinclined to get bogged down in OS version control; I'd like to make
accurate statements at the time of publication. The rest is caveat emptor,
though I will gladly publish any OS plans to update their API so that
people are looking out for it.

On Wed, Nov 13, 2024 at 11:30 AM Greg White <g.white=
40CableLabs.com@dmarc.ietf.org> wrote:

> I also support the adoption of this draft.
>
>
>
> Similar to some other comments, I do wonder about potential evolution of
> the APIs, and how that will be handled given the RFC process.
>
> Perhaps the document could explicitly list the OS version(s) that the
> material applies to.
>
>
>
> On terminology, I noticed the statement in Section 3: “Network devices can
> change the ECN bits in the IP header.”
>
> This should be “Network devices can change the ECN codepoint in the IP
> header.” and it would be worth pointing to RFC3168 and RFC9331 regarding
> the allowed transitions that are expected to occur.
>
> I’ve noticed that even some current vendor documentation refers to the
> obsolete RFC2481 definition of the “ECT bit” and the “CE bit” as opposed to
> the “ECN Field” and its codepoints.
>
>
>
> -Greg
>
>
>
>
>
> *From: *Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> *Organization: *UNIVERSITY OF ABERDEEN
> *Date: *Tuesday, November 12, 2024 at 11:57 PM
> *To: *"tsvwg@ietf.org" <tsvwg@ietf.org>
> *Subject: *[tsvwg] TSVWG Adoption Call for draft-duke-tsvwg-udp-ecn-03 as
> Informational, ending on 29th November 2024
>
>
>
> Hello TSV WG,
>
>
> This is a formal adoption call that will run 2 weeks, ending on 29th
> November 2024. Please respond to this email thread with any comments
> indicating support or objection to adopting this draft as a basis for
> work on ECN support for UDP.
>
> During IETF-121, the WG discussed "Configuring UDP Sockets for ECN for
> Common Platforms" (draft-duke-tsvwg-udp-ecn)  and the sense in the room
> indicated some support for adoption, this email provides an opportunity
> to contribute comments on this planned work.
>
> Best wishes,
> Gorry and Marten
> (tsvwg co-chairs)
>
>
>
> See:
>
> https://datatracker.ietf.org/doc/draft-duke-tsvwg-udp-ecn/
>
>
>
> Abstract
>
>    Explicit Congestion Notification (ECN) applies to all transport
>
>    protocols in principle.  However, it had limited deployment for UDP
>
>    until QUIC became widely adopted.  As a result, documentation of UDP
>
>    socket APIs for ECN on various platforms is sparse.  This document
>
>    records the results of experimenting with these APIs in order to get
>
>    ECN working on UDP for Chromium on Apple, Linux, and Windows
>
>    platforms.
>
>
>
>
>
>
>