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

Christian Huitema <huitema@huitema.net> Thu, 20 July 2023 00:45 UTC

Return-Path: <huitema@huitema.net>
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 29921C1516F3 for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 17:45:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
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 5zx3_Y6ILXYq for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 17:45:03 -0700 (PDT)
Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 6BD2BC151085 for <tsvwg@ietf.org>; Wed, 19 Jul 2023 17:45:03 -0700 (PDT)
Received: from xse432.mail2web.com ([66.113.197.178] helo=xse.mail2web.com) by mx196.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1qMHmr-000Hyd-7m for tsvwg@ietf.org; Thu, 20 Jul 2023 02:45:02 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4R5v914r6jzB73 for <tsvwg@ietf.org>; Wed, 19 Jul 2023 17:44:53 -0700 (PDT)
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1qMHmn-0003Ba-Ev for tsvwg@ietf.org; Wed, 19 Jul 2023 17:44:53 -0700
Received: (qmail 24288 invoked from network); 20 Jul 2023 00:44:52 -0000
Received: from unknown (HELO [10.32.61.242]) (Authenticated-user:_huitema@huitema.net@[192.0.32.236]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <daiya@sfc.wide.ad.jp>; 20 Jul 2023 00:44:52 -0000
Message-ID: <d8a408d9-a569-19c0-742a-89b7f976c60e@huitema.net>
Date: Wed, 19 Jul 2023 17:44:49 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0
Content-Language: en-US
To: Daiya Yuyama <daiya@sfc.wide.ad.jp>, Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg@ietf.org
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>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <86F95E0E-824B-4E19-82EC-4B5ED9E6F962@sfc.wide.ad.jp>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: 66.113.197.178
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.16)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/FrX9FUZIEZ7X6wfd/UIe3PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wK33BxCZ4Q1O8tWwOlQNPYfYzfQXcfqmra3dmoHS4ygvPv pO9baItAKYWmoMsJfL1WuRWrkPihq53YqAd1ENNqBHtNXu1E6L4+KyOXc4QYanQOD0r6/AaHZiEt dTMtMlia0Lmg/jgHfCNZd+W+PXf6iFHuxfACThe7OQWZri8iESue9TLOhN8AYRsvkjfngQAP/qxk sBag8X89IidmLeayzDkBvlIN1pUDU5DU5DggD98cjIN3reG9z0FKKQ5m2Qpw7sOVVcM1Xk+Tdz6g /UMvfWqyN3veeFIMJz/vumcqAwMU9kjfE7EFo+kP5riIEUmxU01QhuxnshSbl6nxbLZ35/xY0uvo WBEOfzq3RG28wI7w4vcwqZanLHsZM8r4s5ZjlHoGly8aneNxj+pRyx6DFxVLaXQjMXzVZeSmCuLu +pFVgpT1b21uZVckGp0ccOZtuBWXiK6eoWgQZnNLL6SbpUc7peFeo3eDQNYbhOKhzzgqmaDn5SlD Y9mmtv6e91aWBLor1oCWetcUjeG94V2XHK7WNoNDjcHtudPS5qD2tR1R1HtNCN39OpEUXdIQa6H0 2IfheFolheac/Ttkaq6REnFzsC48bTEFY06/YbB87Ww8G0LoS8V3Mt1pta8qAcLtCB3G1CwpaI3Z 4ESkMWDVJEenxBoIht3V0nekAoxXAklHhOT8Rv8xkxUknWGwvJ+yuLfHqAnAj7rgKH7+eCmmRgYt FNfcr9eF8Z2QdKB5fVShcA6Xvva2QAVEjpqzANbJ1UfXmet2cbFKoyT/OdZL20SNvs3TPRN6kv0U p33tr20AuXq0T17woJo3avKeADIsy647Mn0zwmGzAi3Zn+YdthRNgs7Ig4l/XErpYn3glZTKFuaT l19W3ISq9+1KiLsESGU+y+fjdgjudZxiTPi+MG1QP35nsYfP84c+RFK3KiZuZ5OAUoGBziSYFLZu u6zX3xxsmqT8l9ARlsTalAaf
X-Report-Abuse-To: spam@quarantine14.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BiDUGVoB4SG0b01elr7m10mwJu8>
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 00:45:07 -0000

If you are going to make requirements on QUIC deployments, you should 
probably discuss that in the QUIC working group. As far as I know, most 
QUIC working group members are very attached to the "end to end 
encryption" of QUIC, and would be very reluctant to add any clear text 
information to the UDP packet.

-- Christian Huitema

On 7/19/2023 12:30 AM, Daiya Yuyama 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?
> 
>> 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
>>>>>
>>>>>
>>>
> 
>