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

Daiya Yuyama <daiya@sfc.wide.ad.jp> Wed, 19 July 2023 11:52 UTC

Return-Path: <daiya@sfc.wide.ad.jp>
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 8A440C1522D7 for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 04:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.402
X-Spam-Level:
X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sfc.wide.ad.jp
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 c5X8Ov-LlxOE for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 04:52:04 -0700 (PDT)
Received: from mail1.sfc.wide.ad.jp (mail1.sfc.wide.ad.jp [203.178.142.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 CFB39C151B1F for <tsvwg@ietf.org>; Wed, 19 Jul 2023 04:52:03 -0700 (PDT)
Received: from smtpclient.apple (201.137.178.217.shared.user.transix.jp [217.178.137.201]) (Authenticated sender: daiya) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id 4A397221B09; Wed, 19 Jul 2023 20:52:02 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1689767522; bh=6Hz6Jeieq04J8NIcdsAFsA2GstavVsiMCTOVlG3+ZTw=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=O5oaJjVmfEFAPq+slHSM1XSvOFIWkONi8ry2E8uJjGNuKd/CcC9EM/JpagMvdjF/k JQS/35f6NecYye2MVcGyToDp5TNDr1gyA15/Zu16bpQMxT4dmVgNbw2fJbNT4JmgNG DLmOd/p5BQh7iBqVjk0iC5k/hgjTkf4Eb4/fUaNvJrIIcOGIDc44qw5V1ggR0vEKTU V/s+MUNX9+kfOac+rMoTpNXlzHnk61ouDe2jdagl5Gm/1D42e1dfA77qqt6UVdhCqg BBqb4ICYXN6LcOILYzzGlXORo8Vr6ljyb6bRJdKB/zq8kMsiCzE0mLQ12i4T+eM8oI sySR/KuiJ41rw==
From: Daiya Yuyama <daiya@sfc.wide.ad.jp>
Message-Id: <86F95E0E-824B-4E19-82EC-4B5ED9E6F962@sfc.wide.ad.jp>
Content-Type: multipart/alternative; boundary="Apple-Mail=_70DF4491-7F35-4AE2-BC0B-E9839D4FCF6B"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Wed, 19 Jul 2023 16:30:38 +0900
In-Reply-To: <CAAK044Q6BDW+_DoHsDMMHPW1jT6SuBy5DLbV_L_MYniRj3J9dA@mail.gmail.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Daiya Yuyama <daiya=40sfc.wide.ad.jp@dmarc.ietf.org>, tsvwg@ietf.org
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
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>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bmI2O-ngCd_EhuJPZR2JIyl_npE>
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: Wed, 19 Jul 2023 11:52:09 -0000

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?

> 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.

Thank you.

Daiya

> 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 <mailto: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 <mailto: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
>> >>
>> >>
>>