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

[Gorry Fairhurst <[e-mail]>]

On 12/07/2023 19:30, Yoshifumi Nishida wrote:
> 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.
I'm less sure: As I see it, the DCCP SC associates a type of connection 
with a socket that is connected, allowing the network (or endpoints) to 
find out the app associated with a particular use of the ports. This 
could identify RTP traffic etc. I don't think this allows provides a 
point to demux to more than one application using the same  open connection.
> It seems to me that it's a bit tricky to use protocol numbers for this 
> purpose.
>
Likely so, and understanding similarities and differences are often 
helpful. I'm not saying one ought to choose the DCCP SC for this, but 
there are many different approaches.
> 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.

I see that also, and for some this could be a desired feature (to hide 
that information) and for other it might not be. I do agree use cases 
are important here!

Gorry

> --
> Yoshi
>
>
> On Wed, Jul 12, 2023 at 8:42 AM Gorry Fairhurst <[e-mail]> 
> 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, [e-mail] 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
>     >>
>     >>
>