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

"" <> Sun, 23 July 2023 03:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C757AC151084 for <>; Sat, 22 Jul 2023 20:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.315
X-Spam-Status: No, score=-1.315 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, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QB8ZPXkYij8X for <>; Sat, 22 Jul 2023 20:30:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DCF1BC14CF1B for <>; Sat, 22 Jul 2023 20:30:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XzK0U3cpOuIZogq38ebpBkuR5A0dYFQ6R0EwJkUoJzw=; b=LK9qgQuGhS1b/oSIWhYs83CDSU YzTFR4EOdjFEvOPomIeXL2VDZXgsIf1v34qnuHyCHEKnEDxd4uouYhxmKNJUuskkBaxJaTwh3vi2O Levazlw9qRyioKaYQt+hNkTfcNVi+F/Yhmh/XsEsaV5EE0kgpyZcgKFly7ekJJuBZxASpufL6Mmom X7Lwniua+utbxV2aAOdHWW2tJyonRWiAoFKbOQdifRx3HW9mORyNlOCdu4AA9++wNOrgrHh3VSg34 9macAqgjOwVWSyknCuH/VGUERZAsCofpge/2uoiO9YU8tur7iJ+MmlqFq2XBKglzHY/7g8+2MPj0A NK0ie3Mg==;
Received: from [] (port=25380 by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <>) id 1qNPnU-00DKt4-26; Sat, 22 Jul 2023 23:30:21 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6968DAE1-9CAD-48EA-BD99-CA8ACCC992FA"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "" <>
In-Reply-To: <>
Date: Sat, 22 Jul 2023 20:30:02 -0700
Cc: Yoshifumi Nishida <>, Gorry Fairhurst <>, Daiya Yuyama <>,
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] New Version Notification for draft-daiya-tsvwg-udp-options-protocol-number-00.txt
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 23 Jul 2023 03:30:26 -0000

> On Jul 20, 2023, at 7:35 AM, Tom Herbert <> wrote:
> Hi Daiya-san,
> Many people don't want middleboxes meddling with *anything* beyond the
> network layer!
> Besides that I'm not sure this is feasible, it would require
> middleboxes to process trailers which is not amenable to efficient
> implementation for a high performance implementation. Also, this type
> of marking could only be used with UDP and doesn't help with other
> protocols. You might want to look at
> draft-cc-v6ops-wlcg-flow-label-marking, it's a more generic solution
> that would work with any transport protocol.
> Tom

If I understand what Daiya-san is trying to accomplish, this would be a step backwards.

The problem is exemplified by netconf; there are 5 different assignments:
	over SSH
	over BEEP
	over SOAP over HTTPS
	over SOAP over BEEP
	over TLS

The goal is to have a field in a transport header that indicates the next protocol, not the entire rest of the protocol stack, e.g., that would allow “next protocol” headers to continue to be chained through the transport layer. This would be useful for TCP, UDP, and SCTP. I don’t know an equivalent capability is already possible in SCTP, but in TCP it is very similar to the “service name option” draft of mine from years ago.

The new proposed doc adds this to UDP - though, AFACIT, the service name option would work there just as well.

AFAICT the bigger issue is that there’s no way to continue the chain past the transport protocol - other protocols don’t universally include a “next protocol” field.

However, trying to use a field the IP header for this purpose goes in the wrong direction. The point is to create a chain as long as the number of layers of protocol and to put that chain inside the protocol layers, not to pull them all out to the IP layer flow label (which would not chain).