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

Yoshifumi Nishida <nsd.ietf@gmail.com> Thu, 20 July 2023 06:24 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 01248C151077 for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 23:24:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 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_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=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 ueM5eGw6YVnG for <tsvwg@ietfa.amsl.com>; Wed, 19 Jul 2023 23:24:17 -0700 (PDT)
Received: from mail-oa1-x2e.google.com (mail-oa1-x2e.google.com [IPv6:2001:4860:4864:20::2e]) (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 528AAC151074 for <tsvwg@ietf.org>; Wed, 19 Jul 2023 23:24:17 -0700 (PDT)
Received: by mail-oa1-x2e.google.com with SMTP id 586e51a60fabf-1b05d63080cso299468fac.2 for <tsvwg@ietf.org>; Wed, 19 Jul 2023 23:24:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1689834256; x=1692426256; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=u7yWJyl5QNUP1Wqf1cYXBDnfD15lZUT8O9MpIGmfchg=; b=kLn4WqLK7j5tMvU1BPiTbeAIDrHkPejzibXokTuQHGDWjILPLrg1sONuhCZY5KXHIv UU/p/xhnawzgJfllFi0BSxB5i3ppKufgMN+kX146/f3i8OBz6m04R6UOTaxlYhRoAJ9p 9ZOFvbUOqE+5F9k7ByFHA/lzulOfYbFL7N8CwAWarH/g34sJXQxtFBedZj/Wmi3jdDrU i5WQcxB1Mwl3SKJaTjYT1vhLBwR6LvNwZ7Eqmr+d4/aO+5LeRo/gziSHsf9LVxhMNY19 IvnvGcxnfSshQd2YVJU4YhQ0gEjaFcCekJxPwL4L3s/xviRfaJcLV1e+GD+78fm5/TdS uO3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689834256; x=1692426256; 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=u7yWJyl5QNUP1Wqf1cYXBDnfD15lZUT8O9MpIGmfchg=; b=Ip3iVsBf5F01/VHxAoMdOhKYDB8IgoXG3kcM48gscRaPYW9IKuMZ0qHD6KFgcTNMNS ZwvngZFGOaxBytc+qlrl/etNwZ4rLOoCft0d6cBDw9LHq6b0OGfH7WF4Ybw7syxgEckt ReDJXDlcCDc3nGxOb9x6MHt1cz7mVjWVw7++IS2oZAJV0zsZvbHRButl5f4HfswMOkev 1dLqQ0/9IgSwNiMtpucv3m5Q1G4J2f/nfqxqiBay7tGpHM4wKDnN1DTBD1dbTISREELr 8CZgZq3CGSlzMM5cTbhnbUbRTzgqsnimZspBMxHJcDTJjHsolk9oYC77HshS/aQ2x0jO 0o/A==
X-Gm-Message-State: ABy/qLaCsR3BOtk3dWROrKRp67bp4A4NThPTFcHksEPHdbSy+cm7xIgk zEDFvaSYGHW5Pg+Nv1bvjJuGcLohM42gdtHtdXI=
X-Google-Smtp-Source: APBJJlECtSAOG1x7vvoCGUWTsEFk1gou96MsW2jF17cRqrhwxdmexUTnvgRI5jhgXiwkVJZddTulAwC4rG7Wao7KORY=
X-Received: by 2002:a05:6870:56a0:b0:1b4:60b3:98c8 with SMTP id p32-20020a05687056a000b001b460b398c8mr953798oao.1.1689834256499; Wed, 19 Jul 2023 23:24:16 -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> <CAAK044Q6BDW+_DoHsDMMHPW1jT6SuBy5DLbV_L_MYniRj3J9dA@mail.gmail.com> <86F95E0E-824B-4E19-82EC-4B5ED9E6F962@sfc.wide.ad.jp>
In-Reply-To: <86F95E0E-824B-4E19-82EC-4B5ED9E6F962@sfc.wide.ad.jp>
From: Yoshifumi Nishida <nsd.ietf@gmail.com>
Date: Wed, 19 Jul 2023 23:24:05 -0700
Message-ID: <CAAK044QeySM_H3TXPdbrXXEMSegZOaemMyr9tYQcVZb8c37WMQ@mail.gmail.com>
To: Daiya Yuyama <daiya@sfc.wide.ad.jp>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Daiya Yuyama <daiya=40sfc.wide.ad.jp@dmarc.ietf.org>, tsvwg@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009689990600e532a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zo5mct7lpTs0ZNVzRXOYQMDIQPM>
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 06:24:21 -0000

Hi Daiya-san

On Wed, Jul 19, 2023 at 4:52 AM Daiya Yuyama <daiya@sfc.wide.ad.jp> 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?
>

Sorry, I was not clear enough. That's not what I meant. I meant it is hard
for middleboxes to distinguish QUIC packets from other UDP traffic as QUIC
packet format is designed in such a way. This is because people don't want
middleboxes to meddle with QUIC traffic. If we put some explicit marks to
QUIC packets, it will negate the effects.

However, this doesn't mean I am denying it. As Gorry mentioned there might
be a case (although I guess it would be limited cases) where we want to put
such marks on QUIC packets. But, I think the draft will need to address
this point anyways.
Perhaps, the draft needs to clarify whether this is for middleboxs'
benefits or endpoints' benefits.

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

That would be great. Thank you so much!
--
Yoshi

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