Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt

Tom Herbert <tom@herbertland.com> Thu, 20 July 2023 14:35 UTC

Return-Path: <tom@herbertland.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 4FCA3C14CE33 for <tsvwg@ietfa.amsl.com>; Thu, 20 Jul 2023 07:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=herbertland.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 JngDPYbzRwVr for <tsvwg@ietfa.amsl.com>; Thu, 20 Jul 2023 07:35:28 -0700 (PDT)
Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1597EC14CE2C for <tsvwg@ietf.org>; Thu, 20 Jul 2023 07:35:28 -0700 (PDT)
Received: by mail-pg1-x532.google.com with SMTP id 41be03b00d2f7-53fa455cd94so442194a12.2 for <tsvwg@ietf.org>; Thu, 20 Jul 2023 07:35:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland.com; s=google; t=1689863727; x=1690468527; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=mRsaH3l3MhmW37XqOL6HyAhicSdxetDJSTuDbACI3Bs=; b=dvZlV2dpTJLKEZRi4+ZZ0cHNuDuVevRiKdbxu+ZAwGKYEtzMD33uJOGeJrRSdaljA4 PWFO4/P3VYfbj9A/IYbJnfPzzKkeuAVZ+XOmTmq6Fy/KqOB72nJsr4DpZ6puHqe9rWB2 Fog7Ll41tLxEps8NNdLiR7kJDeNTkc588ujfbnrVhYNiijOZVnJ45AjydczX5FRwFQRJ WN6t4z2hFD3TLnDVOjIkjSuf8Qcndjew0VerpZWblSHC0QZj+60AJoKdd8sF7U1/rDde 3HIFMUdA7VYcOdhuWJOtUUGYMz/xd4joJPygjeiU9s0qTODfuZpcgGXx0LdyewnGYbiA 9GBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689863727; x=1690468527; h=content-transfer-encoding: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=mRsaH3l3MhmW37XqOL6HyAhicSdxetDJSTuDbACI3Bs=; b=GB3oTZSzu4nwRbV8QOjgZNxO8fpR0PM1YvPLhGpFw5z6GRSLaeai1M1ilTuFW6vWcs ZHE1+kt9FVLU5M3ZHgyPDu/wTqvWwgjFKFCfFOr+ttcBrl/yrbaGn4OFx6VX5QE5m6sz Zem+fnA/D3o65S1DkQzaZhgS4chqC9k0jjxSbRXYDdFkk2DALbx5BXRwkB+2TsX1/cp2 pJCBDBqJ6W9Jc2uFAJ+6ThcwjSeTgJOjG3BaXuexNIz4dGsqt9RkBMBVF1aMDEgXiWn+ mVfKvQzPg5xOKd9SOCFx9Ki8OeW76cApB/iCwjZTPnwrJ3ROYVWr/GBhbw43SNmF+1t0 sqCA==
X-Gm-Message-State: ABy/qLakAhR8Z2VDk+Qyh1lkiGSj/Y1zw+LneNfViY87OYsprlrHceC9 koSc1JP3Dz7es5wZ2EaTxZcTFRSI5MJ0TU9jrKP6Yg==
X-Google-Smtp-Source: APBJJlEDeppuGHFmJwenVrTpBafaVVLuc7/XApWBSRefMP5j/I06GdCs7VqTZJpZWoqeSc7TY5xWqaJmE8oLyU6AF/o=
X-Received: by 2002:a17:90a:51e4:b0:262:de1a:6028 with SMTP id u91-20020a17090a51e400b00262de1a6028mr16721706pjh.13.1689863727208; Thu, 20 Jul 2023 07:35:27 -0700 (PDT)
MIME-Version: 1.0
References: <168903260541.49852.5537122429979483346@ietfa.amsl.com> <591bfafb-ff0a-427d-5e14-0de776437fd6@sfc.wide.ad.jp> <2b1306db-6b12-dcce-0018-eb1a10f22056@erg.abdn.ac.uk> <CAAK044Q6BDW+_DoHsDMMHPW1jT6SuBy5DLbV_L_MYniRj3J9dA@mail.gmail.com> <86F95E0E-824B-4E19-82EC-4B5ED9E6F962@sfc.wide.ad.jp> <CAAK044QeySM_H3TXPdbrXXEMSegZOaemMyr9tYQcVZb8c37WMQ@mail.gmail.com>
In-Reply-To: <CAAK044QeySM_H3TXPdbrXXEMSegZOaemMyr9tYQcVZb8c37WMQ@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 20 Jul 2023 07:35:15 -0700
Message-ID: <CALx6S35RiOBV80ELvpg6oN09wX8G7emuk2EG3xfHJs3ep1kezw@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: Daiya Yuyama <daiya@sfc.wide.ad.jp>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Daiya Yuyama <daiya=40sfc.wide.ad.jp@dmarc.ietf.org>, tsvwg@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/c-fSao4JlHpsZ6n3DSPNv6igK60>
Subject: Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jul 2023 14:35:32 -0000

On Wed, Jul 19, 2023 at 11:24 PM Yoshifumi Nishida <nsd.ietf@gmail.com> wrote:
>
> Hi Daiya-san
>
> On Wed, Jul 19, 2023 at 4:52 AM Daiya Yuyama <daiya@sfc.wide.ad.jp> wrote:
>>
>> Dear Nishida-san
>>
>> Thank you for your comments.
>>
>> > Another point is although the doc mentioned QUIC, I think QUIC is designed in the opposite way to blend into other UDP traffic so that it can avoid protocol ossifications.
>>
>> Does it mean that QUIC enables other protocols with the same port number to co-exist?
>
>

Hi Daiya-san,

> Sorry, I was not clear enough. That's not what I meant. I meant it is hard for middleboxes to distinguish QUIC packets from other UDP traffic as QUIC packet format is designed in such a way. This is because people don't want middleboxes to meddle with QUIC traffic. If we put some explicit marks to QUIC packets, it will negate the effects.

Hi Daiya-san,

Many people don't want middleboxes meddling with *anything* beyond the
network layer!

Besides that I'm not sure this is feasible, it would require
middleboxes to process trailers which is not amenable to efficient
implementation for a high performance implementation. Also, this type
of marking could only be used with UDP and doesn't help with other
protocols. You might want to look at
draft-cc-v6ops-wlcg-flow-label-marking, it's a more generic solution
that would work with any transport protocol.

Tom


Tom
>
> However, this doesn't mean I am denying it. As Gorry mentioned there might be a case (although I guess it would be limited cases) where we want to put such marks on QUIC packets. But, I think the draft will need to address this point anyways.
> Perhaps, the draft needs to clarify whether this is for middleboxs' benefits or endpoints' benefits.
>>
>>
>> > In any case, I think it would be great to have some use cases for having this option.
>>
>> We, too, believe that use cases are important.I will reply another email about use cases.
>
>
> That would be great. Thank you so much!
> --
> Yoshi
>>
>> 2023/07/13 3:30、Yoshifumi Nishida <nsd.ietf@gmail.com>のメール:
>>
>> Hi
>> I am thinking that there might be some conceptual difference between DCCP service code and this proposal.
>> DCCP service code can be used for demultiplexing at the endpoints. Apps can use a single socket for multiple application services with it.
>> It seems to me that it's a bit tricky to use protocol numbers for this purpose.
>>
>> Another point is although the doc mentioned QUIC, I think QUIC is designed in the opposite way to blend into other UDP traffic so that it can avoid protocol ossifications.
>> In any case, I think it would be great to have some use cases for having this option.
>> --
>> Yoshi
>>
>>
>> On Wed, Jul 12, 2023 at 8:42 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>>>
>>> On 11/07/2023 18:47, Daiya Yuyama wrote:
>>> > Dear all
>>> >
>>> > We have submitted a draft that defines the protocol number option in
>>> > UDP options. The protocol number option specifies the protocol
>>> > immediately following the UDP header.
>>> >
>>> > https://datatracker.ietf.org/doc/draft-daiya-tsvwg-udp-options-protocol-number/
>>> >
>>> >
>>> > Currently, the only information about the packet encapsulated in UDP
>>> > is the port number corresponding to the service. In addition,
>>> > UDP-based protocols such as QUIC are increasingly used as transport
>>> > for applications.
>>> > When using such protocols, it is not possible to provide the UDP layer
>>> > with information about the transport layer protocol that follows the
>>> > UDP header. The protocol number option provides this information.
>>> >
>>> > We believe this option would be beneficial for extending the transport
>>> > protocol with UDP.
>>> >
>>> > If you are interested in it or have any comments, I really appreciate
>>> > your feedback or comments.
>>> >
>>> > Thank you.
>>> >
>>> > Daiya
>>>
>>> Thanks Daiya for this submission. This draft sounds like it could be
>>> helpful in some cases.
>>>
>>> I see from the spec uses unsigned 16 bit values to identify the next
>>> header, and I wondered what sort of values you thought would be needed?
>>>
>>> I see many potential options:
>>>
>>> * Would the values simply follow the port registry assignments, which is
>>> 16 bits.
>>>
>>> * IANA also has defined an ASCII service name (in the port registry),
>>> which is not 16 bits.
>>>
>>> * In the past, we defined a 4 byte Service Codes for DCCP, to describe
>>> the application being carried by DCCP, and there seems some parallels
>>> with the usage:
>>>
>>> https://www.iana.org/assignments/service-codes/service-codes.xhtml
>>>
>>> * IPv6 defines a NH value - for transport values this uses:
>>>
>>> https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
>>>
>>> * And, as the draft currently suggests, the IETF could also decide to
>>> define new IANA registry.
>>>
>>> Which is best and why?
>>>
>>> Gorry
>>>
>>> >
>>> > On 2023/07/11 8:43, internet-drafts@ietf.org wrote:
>>> >>
>>> >> A new version of I-D,
>>> >> draft-daiya-tsvwg-udp-options-protocol-number-00.txt
>>> >> has been successfully submitted by Daiya Yuyama and posted to the
>>> >> IETF repository.
>>> >>
>>> >> Name:        draft-daiya-tsvwg-udp-options-protocol-number
>>> >> Revision:    00
>>> >> Title:        Protocol Number Option in UDP Options
>>> >> Document date:    2023-07-10
>>> >> Group:        Individual Submission
>>> >> Pages:        6
>>> >> URL:
>>> >> https://www.ietf.org/archive/id/draft-daiya-tsvwg-udp-options-protocol-number-00.txt
>>> >> Status:
>>> >> https://datatracker.ietf.org/doc/draft-daiya-tsvwg-udp-options-protocol-number/
>>> >> Html:
>>> >> https://www.ietf.org/archive/id/draft-daiya-tsvwg-udp-options-protocol-number-00.html
>>> >> Htmlized:
>>> >> https://datatracker.ietf.org/doc/html/draft-daiya-tsvwg-udp-options-protocol-number
>>> >>
>>> >>
>>> >> Abstract:
>>> >>     This document defines the protocol number option in UDP options.
>>> >> The
>>> >>     protocol number option specifies the protocol immediately following
>>> >>     the UDP header.
>>> >>
>>> >>
>>> >>
>>> >> The IETF Secretariat
>>> >>
>>> >>
>>>
>>