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 07:29 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 11ECBC151081 for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 00:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.295
X-Spam-Level:
X-Spam-Status: No, score=-4.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=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 qXv4YORBxatr for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 00:29:10 -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 470A4C151075 for <tsvwg@ietf.org>; Wed, 19 Jul 2023 00:29:08 -0700 (PDT)
Received: from smtpclient.apple (i118-21-119-55.s30.a048.ap.plala.or.jp [118.21.119.55]) (Authenticated sender: daiya) by mail1.sfc.wide.ad.jp (Postfix) with ESMTPSA id D93AC221F9B; Wed, 19 Jul 2023 16:29:04 +0900 (JST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sfc.wide.ad.jp; s=mail1; t=1689751744; bh=WHaax9fAdAyI09oBoMrMjkeAwCcgtwzsnJcctPZEzyI=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=hrm0SeA5vZ8A2ogICsgq/gN24Od5/leavF6lyZcHvR1TXfXA5arLgT/9g6eFcviXC wE02jtfxX5o3tirDNUt7J6swfQ24jVhtAzeD1o01jvpzpnD01AO66/XntzRYbliU+u irMSN1ktMAhBGoSGB/p01KJwXskDLk1J5wnZwtz9rsCPNWz0DelQJD39FVFsARskI7 m1YNsKaJzc4t1EfYCsAoU4olDQqcmqzVucerpeowBViFE8YPvlFSt/eKxOADMPf3Lf xbW+88Jb8wWk9aWS4tYqkP+HieJzlF9WvM5fRxOxkHLsVWVq/HrLkFvBQxmiWnOHSu WS6P27sa+OykQ==
From: Daiya Yuyama <daiya@sfc.wide.ad.jp>
Message-Id: <09444896-78EC-457B-B3E0-CF433E6472B5@sfc.wide.ad.jp>
Content-Type: multipart/alternative; boundary="Apple-Mail=_A8A3E59D-0596-473E-AB81-97A9FF6FCD7E"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
Date: Wed, 19 Jul 2023 16:28:54 +0900
In-Reply-To: <2b1306db-6b12-dcce-0018-eb1a10f22056@erg.abdn.ac.uk>
Cc: tsvwg@ietf.org, Hirochika Asai <panda@wide.ad.jp>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
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>
X-Mailer: Apple Mail (2.3731.600.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/FDnNh-uU6CJ6912M_jhALauNIQg>
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 07:29:15 -0000

Dear Gorry,

Thank you for your comment.

We had planned to discuss the details of the numbers and add them to the next version of the document. Once again, I have discussed this with the co-author, but have not yet been able to make a decision.

Mainly, I am not sure if this option should only be used for transport protocols implemented based on UDP.
- If so, the number should only be able to indicate the transport protocol.
- If not, and we also want to represent the application layer protocol, then you need to be able to represent both the transport protocol and the application protocol in one number space.
- Alternatively, the use of strings should be considered, but may not fit the binary format UDP options.

We would like to discuss these points during IETF 117.

Thank you.

Daiya

> 2023/07/13 0:42、Gorry Fairhurst <gorry@erg.abdn.ac.uk>のメール:
> 
> 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