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

Yoshifumi Nishida <nsd.ietf@gmail.com> Wed, 12 July 2023 18:31 UTC

Return-Path: <nsd.ietf@gmail.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 B83B8C1595FD for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2023 11:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=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=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 M1f3UHrpQdP5 for <tsvwg@ietfa.amsl.com>; Wed, 12 Jul 2023 11:31:36 -0700 (PDT)
Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) (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 E60D6C1519A8 for <tsvwg@ietf.org>; Wed, 12 Jul 2023 11:30:49 -0700 (PDT)
Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-1b7233e594eso3011866fac.1 for <tsvwg@ietf.org>; Wed, 12 Jul 2023 11:30:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689186648; x=1691778648; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1FDHVazwNXuCueyq8ALRRJ5ozbjOwsZ7Qd1G5w/fEHU=; b=AFD0gqlxBXHDTl7CqJUbHEy8vFlh/BxExsSSxIv31WI3kx0eCt6tmbeIfjTRhGPkNl KbB5RYXxCfJu/lDAK0c5mDPs4KZ738OjeUG27yE3V8qE7qXzdFUwMQZDFgalJWoV94i6 oriIrL+6Eh0eG120G//rt9bugVpGVCvf2lmQ//yNzeuxGH0vav839xw38OJtAYl8M1xj z3FCAJtlxIVjxS+PLVPwMxUb/Jl3iL9H66GY9DEZvweDfsogIdKBLlECa3F9ZPLzC61R kTosIaoS3dBbI3n3+gBvqlWHcIhaAdgRzuw8B2v1tSPfTawXDlrMr4c9besIDr8BilXY Pu1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689186648; x=1691778648; h=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=1FDHVazwNXuCueyq8ALRRJ5ozbjOwsZ7Qd1G5w/fEHU=; b=P7in267EIP3pD9QWpBLhQ2UCK1cr50mXJHt/d0wYTGJHPQTM37wLhLts95CetPIlrg MWpu/J2SRbf3SY6jKZnoGiwMT+IMDT30ApqYMp2+YU+D+t6I/pSmJmJLgU8PR58m4KDg xHOM9osCh3BZdJ5adOUr1D6qSAO8/2HumndwnC0E2ikqFFa0TF83mulkeEI5CdUF+KP8 xGbYlkXs2e0lQ/DWv4jokIuEYloeWhcGQliDNBOcG0PE6qpnJckkh9DDaoDZzUjjhtsk dKbVDGVRRjMv1huZ3xK1gbvqtzW7vb0Cv3e/KbZRhJuryhODK5PIN/L3Ktj1b7rQ7lI7 1HCw==
X-Gm-Message-State: ABy/qLZ0oUodYkHEgzo+CHL07a+Ve1pWsJWfevlS0B+WPHyTvLgEMWSM TbD2wacFWXCR0KV4WjCuUvh7Cvn5QqrrRWqUHbifg2RA0Y0=
X-Google-Smtp-Source: APBJJlHmFzQqhvsCjxHWP3+xnf6NCaGbFAp8CMqhSZGTnDOro0Kx+2Erda6T2IukxvF1BEJVWtBhpBYRkFccFqZhXjg=
X-Received: by 2002:a05:6870:5691:b0:1b3:eec8:fa94 with SMTP id p17-20020a056870569100b001b3eec8fa94mr22200849oao.7.1689186648188; Wed, 12 Jul 2023 11:30:48 -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>
In-Reply-To: <2b1306db-6b12-dcce-0018-eb1a10f22056@erg.abdn.ac.uk>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 12 Jul 2023 11:30:37 -0700
Message-ID: <CAAK044Q6BDW+_DoHsDMMHPW1jT6SuBy5DLbV_L_MYniRj3J9dA@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Daiya Yuyama <daiya=40sfc.wide.ad.jp@dmarc.ietf.org>, tsvwg@ietf.org, Hirochika Asai <panda@wide.ad.jp>
Content-Type: multipart/alternative; boundary="0000000000001fec5506004e6a9e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Nx9Recv1LJCBNnHxrfNldef3Ppw>
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, 12 Jul 2023 18:31:39 -0000

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