TSVWG Virtual Interim, 16:00 UTC; 3rd September 2021

Notetaker: Jonathan Morton
Brief delay due to organisational snafu… actual start 16:10 UTC

1. Agenda & Organisation (10 mins)

Agenda bashing:
PLPMTUD draft up for adoption, proposed to go parallel with UDP Options main draft.
Tom Jones will speak about UDP Options implementation status, too.

2. Chairs Update: (5 mins)

Status of L4S WGLC to be conveyed by e-mail, maybe later today.

3. J. Touch: UDP Options (30 mins)

draft-ietf-tsvwg-udp-options 

Significant updates to text in -13 rev, follows extensive discussion on list.
Some opinions may be inadvertently lost in the chaos.

Some pending issues:

• Is the OCS field REQUIRED and is this 4-byte aligned? The OCS will appear in all UDP packets using UDP options and have a fixed 2-byte format (type and length no longer required). To be set to zero to indicate “not used” (in the same spirit as the UDP checksum). Various alignment option discussed, and proposed to be aligned to the first 4-byte boundary, with zero-fill as needed. If aligned, discussion of swapping bytes if not aligned will be removed.
• UNSAFE encoding codepoint(s)? This could be indicated as a single type byte from a block of 32 from the UDP option values, i.e., no longer using a single UNSAFE prefix byte. The WG needs to consider alternate terms for safe/unsafe, if this is thought confusing (critical vs elective? TBD). There is a need to update discussion to describe receiver packet processing when safe vs. unsafe options are unknown and include a reminder that unsafe options always hidden from legacy receivers within a FRAG.
• FRAG location? the FRAG option should appear immediately after OCS when used, to support DMA; per-frag UDP options to appear after FRAG option but before fragment data; per-segment (pre-fragmentation/post-reassembly) UDP options to appear after user data (i.e., the reassembled segment and post-reassembly options will appear in the same place, as if fragmentation had not occurred.)
• FRAG support, MRSS minimum requirements? Some form of FRAG support will be required, which needs to be agreed: (at least 2 fragments per segment; we discussed X=1280 and X=1500 and 2*X=4096, TBD).

Discussion of semantics upon receiving unknown UNSAFE option:
Legacy receivers ignore UDP payload after the transport-layer length.
IP payload length not covered by transport-layer length indicates options area.
Unknown UNSAFE options should behave like a legacy receiver, that’s the point!

Needs more treatment of error handling in the draft.
Much work on the text is planned anyway, now that the technical basics are established.

The FRAG receiver requirements will state a minimum that can be expected on 0-RTT conditions.
With an RTT delay, a sender can query the receiver to exceed the minimum.
A reasonable minimum RMSS may be 2 frags, 2560 bytes (2x 1280). To discuss on-list.

Still some debate over the API boundary and level of application control over the use options.
Also debate over location of per-datagram options in a fragmented datagram.
Some think that application control of options per individual packet could be excessive.
To continue debate on list.

The next rev will be -14 in 2 weeks, then more extensive clarification after that.

4. T. Jones: Datagram PLPMTUD for UDP Options (Individual ID) (15 mins)

draft-fairhurst-tsvwg-udp-options-dplpmtud

DPLPMTUD is a bit of a mouthful…
This is a “mapping draft” to RFC-8899 for the UDP Options context.
This will enable probing PLPMTU, validation, etc.
Recent revisions were fairly minor, now on -05.

Two implementations of UDP Options include DPLPMTUD: Scapy, FreeBSD.
Should the WG adopt, as a pair with UDP Options?
Show of hands: 12 aye, 1 nay - will confirm on list

4.1. T. Jones: UDP Options implementation status

There is a standing invitation to inform about implementation progress.
Test suite & tooling in Scapy, kernel implementation in FreeBSD.
This combination enables continuous integration testing.

FreeBSD implementation is -09 draft, text has advanced significantly since.
Applications and users will be needed to upstream (as well as update).
Several things are not implemented yet. It omits some currently required-to-support options whose format has been in flux (FRAG, UNSAFE), and also ACS.

Documentation of socket API: separate issues for spec and implementation.
Abstract socket API could be documented in Informational track; to discuss.
Implementation will document in eg. man pages.

Call for interest from application developers: talk to Joe and/or Tom.

5. SCTP

5.1 M. Tuexen: SCTP.bis review of WGLC (10 minutes)

draft-ietf-tsvwg-rfc4960-bis

Revision -14 includes some clarification updates. Technical changes minor.
Includes a list of changes since RFC-4960.
Clarification of INIT and INIT-ACK due to implementation bugs in Linux & BSD.

WGLC comments were addressed, no remaining open issues, work considered complete.
Gorry will take it forward, and submit a writeup requesting publication.
Still a WG item at the moment, please bring up any new/remaining concerns.

5.2 M. Tuexen: SCTP in a container environment (10 minutes)

(Slides, no draft)

This has to do with a specific application of NAT in clusters.
Simple solutions may be preferred, and ideally without NAT.

Some suggestions based on TCP practice.

• These don’t handle multihoming, key SCTP feature.

Scalability & fault tolerance important.

• Single inline distributor simplifies endpoint support, single point of failure.
• Multiple inline distributors more fault tolerant, but requires endpoint support.
• Multiple out-of-line distributors may offer a good solution.
  • Upside, great scalability & fault tolerance, easy implementation.
  • Downside, need public IP address for each physical cluster node.

Feedback welcome.

AD: The possibility of setting up dedicated SCTP WG was mooted. Some positive reactions.

5.3 NAT alternatives for SCTP (15 mins)

C. Porfiri: draft-porfiri-tsvwg-sctp-natsupp

Many different use cases for having SCTP hosts behind NAT.

• Focus on cluster use cases.

Distributed SCTP Endpoints (Kubernetes)

• used as a lightweight clustering solution with fault tolerance
• have trouble with NAT at present

Proposal:

• NAT parses only SCTP Common Header
• notifies collisions at INIT, endpoints react by changing Source Endpoint
• as simple as possible, doesn’t keep Association State, just a supervisor & forwarder
• multihoming handled by normal procedure after NAT established
• NAT not responsible for load balancing

Overall, a simplified version of draft-ietf-tsvwg-natsupp (below).

5.4 NAT alternatives for SCTP (15 mins)

M. Tuexen: draft-ietf-tsvwg-natsupp 

Focus on consumer/SOHO NAT rather than clusters.
Try not to change port numbers.
Brief listing of differences vice C. Porfiri’s approach.

Gorry asks: Does the WG think it useful to publish the ID with some small updayed tet, and then supplement for other use cases, or not?

• Suggestion that document taken back for editing, will discuss & take advice.
• Why does the simpler use case (SOHO) need more complexity than the big cluster?

Discussion expected on list.

6. Any Other Business (if time permits)

A second virtual interim expected before next IETF, and will be notified by the WG mailing list.