[tsvwg] Re: Mohamed Boucadair's Discuss on draft-ietf-tsvwg-usr-exp-12: (with DISCUSS and COMMENT)

["[e-mail]" <[e-mail]>]

Hi, Mohammed,

Thank you for your review.

Notes below.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Sep 9, 2025, at 9:14 AM, Mohamed Boucadair via Datatracker <[e-mail]> wrote:
> 
> Mohamed Boucadair has entered the following ballot position for
> draft-ietf-tsvwg-usr-exp-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-usr-exp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Hi Joe,
> 
> Thank you for the effort put into this specification.
> 
> Thanks to Niclas Comstedt for the OPSDIR review and to Joe for engaging and
> making changes to address those comments.
> 
> I support the assignment of the new port numbers in the user port range.
> However, I have some concerns about the use of experiment identifiers.
> 
> # Incentives & Operational Implications
> 
> (1) An experimenter can use a dynamic port number and make the appropriate
> configuration to pass through filtering devices, at the server side. Why
> defining an additional ID would be helpful here compared to that approach or
> leverage upper layer mechanisms?

The typical issue is that some administrators will/can configure firewalls for assignable ports, but in some case, either by design or policy, dynamic ports cannot similarly be configured.

> (2) Making use of an additional ID also increases the amount of configuration
> data that need to be shared with involved endpoints and which can’t be
> discovered using conventional means. Things are even complicated for those who
> decide to make use of several ports given that there is not correlation between
> an ID and the port number (per Section 4).

PExIDs are for uses of the experiment ports, whose endpoints are necessarily coordinated by the experiment designer. That designer would know which experiment port was being used if multiple port numbers were part of the experiment.


> (3) The introduction of the new id has also implications on the protocol
> machinery as there are extra steps that are needed to be supported only for
> testing purposes.

Yes; this is considered a reasonable additional effort for the privilege of shared use of the experiment ports. We don’t have enough ports to give them out or coordinate their use for short-term experiments. 

> (4) Although this is not recommended in the spec, the document discusses
> approaches such as using transport options to convey the new Id.

We don’t recommend for or against that approach.

> That approach
> and similar ones are suboptimal in some contexts where the option are stripped
> by on-path device.

We cannot write protocol specs for devices that violate specs. That’s “laws for the lawless” and wasted effort.

Devices should NEVER modify a packet that isn’t received at that device EXCEPT when that authority has been delegated by the actual endpoint (e.g., by a sysadmin at the boundary of an enterprise). In the exception case it is the system that logically accepts the packet.

> (5) The approach may require updated to existing device/functions (Section 6)

Yes, it may - that’s the cost of doing some experiments.

> # Why registering Experiment Identifiers is needed here?
> 
> CURRENT:
>   This document also creates a PExID registry, in addition to the IANA
>   service names and ports registry [SP-reg], to reduce the potential
>   that experimental uses of PExIDs interfere with each other if they
>   are tested in the same environment or in the public Internet.
> 
> (1) Unlike TCP/UDP ExIDs which may have interoperability implications, I fail
> to see the benefit of maintaining an IANA registry for local experiment
> identifiers. Such identifiers (if needed) can be agreed out-of-band as part of
> the setup of the experiment.

Like TCP/UDP ExIDs, the point is not to coordinate endpoints to use the same ID. In both cases, the registry exists to prevent others from accidentally using the same ID, i.e., to keep experiments separate.

> (2) The identity that decides to bind several experiments to a seme port number
> will obviously pick distinct identifiers independent of what other entities
> picked (the connection will be handled using distinct IP addressed anyway).

There is no way for such an entity to know that it has chosen IDs that others don’t use without a registry. The registry is a convenience for willing participants. It isn’t enforceable.

> (3) The expectation should be still what RFC3692 says on the matter:
> 
>   By definition, experimental numbers are not guaranteed to be
>   unique in any environment other than one where the local system
>   administrator has chosen to use a particular number for a particular
>   purpose and can ensure that a particular value is not already in use
>   for some other purpose.

That expectation is valid when PExIDs are not used; the point of this document is to relax that advice, and the registry is what helps different administrators coordinate.

> (4) If we get rid of the public registry, concurrent experiments bound to a
> same IP address won’t require 32-bit identifiers

Without a PExID or similar identifier, there would be no way for concurrent experiments to share the same port on the same IP address. However, the primary intent here is for services not bound to a specific IP address to also share use of a port.

> CURRENT:
>   This document reserves user ports for experimentation and describes
>   the use of 32-bit unsigned protocol experiment identifiers (PExIDs)
>   to differentiate shared use of these ports for concurrent
>   experiments

I’m not sure what change the above is intended to discuss. Can you clarify?

> # Migration/Transition
> 
> CURRENT:
>   If an
>   assigned port is granted to a formerly experimental service with a
>   registered PExID, that service MUST NOT continue to use the
>   experiment ports (even using that PExID) in a deployed system
>   available to the public (i.e., a 'shipped product'), per Section 1.1
>   of [RFC3692].
> 
> I don’t see how we can enforce MUST NOT here. Migration and transition plan is
> really a decision that is local to the experimenters.

We have many requirements like this that are not strictly enforceable; nearly all those in RFC 6335 and RFC 7605 are similar. These are used by the port “expert review” team, e.g., this issue would be checked when a service using a PExID applied for an assigned port by checking the protocol spec that would apply if a port assignment were made.

> What prevents experimenters from running the ‘public’ service using the
> assigned port number, but still use the exp port numbers for an experiment
> variant of the service?

Nothing; we’re saying that deployed services cannot continue to use the experiment ports. 

> # Intended for use with PExIDs only
> 
> CURRENT:
>    Assignment Notes        Intended for use with PExIDs only
> 
> However, there is nothing in the specification to ensure that.
> 
> What prevents using the new port numbers without the PxIDs?

The SHOULDs in this doc., presumably.

> Why is that would
> be harmful at the first place?

PExIDs allow experiments to expand beyond private environments; RFC3692 explains why doing so without PExIDs would be harmful.\

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Define early in the document the concept of “association”

This document does not define a single approach as to how  PExIDs are indicated within either stateful or stateless associations (i.e., connection-oriented with explicitly coordinated state and connectionless exchanges with cached state, vs. those without).

> # (nit) consider tagging this part in Section 1 as an aside element:
> 
> CURRENT:
>   Note that service
>   names are case-insensitive, but are shown in upper-case throughout
>   this document to improve their visibility.

It seemed simpler to remove the “note that” from the sentence.

> # On Firewalls
> 
> These are not the only functions that can filter connections. There may be,
> e.g., NATs with filtering behavior. Maybe generalize and reason about “device
> with filtering” instead of sole firewall mention.

This method won’t necessarily work through NATs because the PExID is not part of the NAT state, so yes, this is somewhat limited to firewall-like devices.

> # (nit)
> 
> OLD: "[IANA-THIS-RFC] defines PExIDs that are that are recommended for
> NEW: "[IANA-THIS-RFC] defines PExIDs that are recommended for

Per another reviewer, this was changed to “PExIDs, which are recommended"

> # Data Path & OS Modification
> 
> I don’t parse the following in Section 4:
> 
> CURRENT:
>   Unlike ExIDs, PExIDs are
>   used in the data path and require no OS modification.

Changed to:
Unlike ExIDs, PExIDs are used in the data path and can be used by applications with no OS modification. 

> Also, the OS claim depends on the transport protocol and how the id is conveyed.

All protocols can insert the PExID in the data stream; this does not require OS mods. Use of some other methods may require OS support, but not specifically for PExIDs, i.e., this document makes no demands for OS mods.

> # Other experiment uses
> 
> Section 4:
>   This document also encourages the use of these PExIDs for
>   experiments using existing experiment ports, i.e., system ports EXP1
>   (#1021) and EXP2 (#1022).
> 
> I guess the intended consumer for this is the experimenter AND the underlying
> implementation that will inject the ids. If my understanding is correct, then
> the language/intent should be made clear.

Revised by a previous reviewer as:

The use of these PExIDs for experiments using existing experiment ports, i.e., system ports EXP1 (#1021) and EXP2 (#1022) is RECOMMENDED.

> # Internal (in)consistency
> 
> (1)
> 
> Section 4 says:
>   Experimenters SHOULD register PExIDs with IANA and include them at
>   the beginning of their transport data, i.e., at the front of each
>                                              ^^^^^^^^^^^^^^^^^^^^^^
>   separate message or byte stream, as a 32-bit unsigned integer in
>   ^^^^^^^^^^^^^^^^
>   network standard byte order.

It now says “typically in front of each separate message payload or byte stream"

> Section 5.1
> 
>   PExIDs are intended to be placed in network-standard byte order at
>   the beginning of each independent transport data payload.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Or byte stream

 (which is implicitly a single payload)

> 
>   For connection-oriented transport protocols, such as TCP [RFC9293],
>   SCTP [RFC9260], and DCCP [RFC4340], the PExID is typically sent once
>                                                              ^^^^^^^^^^
>   for each connection at the beginning of the user transfer and echoed
>   upon receipt

Yes, that’s the beginning of the primary byte stream.

> Or
> 
>   In other cases, the
>   PExID can be transferred elsewhere in the data stream, as specified
>                ^^^^^^^^^^^^^^^^^^^^^^
>   by the user application.

I removed that; agreed it is confusing.

> Section 5.3
> 
>   For UDP, a similar mechanism
>   SHOULD be included with each packet if UDP options are supported
>   [TH25].

Replaced “included” with “used”. I.e., use a UDP option per packet.

> Seems to me that there is deviation of the general note vs. specifics. Please
> double check through the document (first, elsewhere, trailer part, etc.).

The PExID typically is used as the first part of each data transfer in the user data, but can be in headers when there are headers that already support their use. We get into the latter nuance where needed, but focus on the former.

> (2)
> 
> Section 5.3 says:
> 
>   For stateful (connection-oriented) associations, the PExID SHOULD be
>   indicated during the initial state negotiation of the transport or
>   security protocol.
> 
> There is a tension between the various SHOULD out there and the following
> statement in Section 5.3:
> 
>   This document does not define a single approach to
>   indicating PExIDs for either stateful or connectionless
>   Associations.

It SHOULD be indicated, but we don’t specify how. That seems consistent.

> # Echoing IDs
> 
> Section 5.1:
>   For connectionless transport protocols, such as UDP [RFC768], the
>   PExID is typically included at the beginning of every message in
>   both directions.
> 
> (1) Is there any expected behavior of this was not echoed?

No.

> (2) I guess that the same PExID is expected through the same connection. What
> is expected if any variation is observed between messages in the same direction?

They would be interpreted as independent uses of the experiment port; that’s exactly the purpose of the PExIDs.

> # SCTP Update
> 
> Section 5.2:
>   For SCTP using only PExIDs for that purpose, users SHOULD send the
>   PExID ordered and reliably as the first user message using PPID of
>   #PPID1 in stream 0 (the default stream). Until the PExID user
>   message is echoed back on stream 0, user messages on stream 0 SHOULD
>   be sent ordered and the user SHOULD avoid transmitting user messages
>   on other streams. The echoed user message SHOULD use the PPID of
>   #PPID1 assigned for this purpose. That PExID user message MUST
>   contain only the PExID as a 32-bit unsigned integer in network
>   standard byte order.
> 
> Isn’t this updating the base SCTP spec?

SCTP advisors have suggested that the text above is just a “use” of the PPID mechanism. 

> # Data outside the transport header
> 
> Section 6:
>   PExIDs help differentiate different uses of the same experimental
>   transport port number using data outside the transport header,
> 
> This statement can not be generalized as the spec also describes approaches
> where this is part of the transport header (TCP option, for example).

Revised as:

PExIDs help differentiate different uses of the same experimental transport port number using data that augments the port number of the transport header


> # Advanced ACL
> 
> You may check
> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-extensions-17#name-payload-based-filtering
> that describes a feature deployed out there and which may be useful to control
> filtering based on specific PExIDs.
> 
> That can be cited in Section 6.

I’m hesitant to suggest use of a method that has not yet been widely deployed in this document.

> 
> Cheers,
> Med
> 
> 
>