TSVWG Virtual Interim, 3rd September 2021
Notetaker: Jonathan Morton
Brief delay due to organisational snafu… actual start 16:10 UTC

IETF TSVWG Interim Meeting
Scheduled: 3 Sep 2021 at 16:00 UTC; (17:00 UK) (09:00 PST; 12:00 EST) (midnight, Singapore).
Duration 2h
https://meetings.conf.meetecho.com/interim/?short=36873ae2-8377-4a47-a4ca-07f65bfaf8d4

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:

• OCS field to be REQUIRED and 4-byte aligned? Probably not alignment.
• UNSAFE encoding codepoint(s)?
• FRAG support, MRSS minimum requirements (2 frags? 2600/3000/4096 bytes?).

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 technical basics are established.

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

Still some debate over API boundary and level of application control over options.
Particularly the degree of control over fragmentation.
Also debate over location of per-datagram options in fragmented datagrams.
Some think application control of options per individual packet could be excessive.
To debate on list.

Next rev -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.
Enables probing connectivity, validation, etc.
Recent revs 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

4bis. T. Jones: UDP Options implementation status

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.

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: Possibility of setting up dedicated SCTP WG 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.