Minutes IETF110: tsvwg
minutes-110-tsvwg-04

TSVWG at IETF 110 - March 6-12 2021

17:00-19:00 Monday Session III ( 2 hours )

    Agenda

    Chairs Update: (15 mins)
    RFC’s completed/in Queue:
    RFC 8837 - draft-ietf-tsvwg-rtcweb-qos

    With IESG:
    draft-ietf-tsvwg-natsupp (AD Review) 
	Document Shepherd: Gorry
    draft-ietf-tsvwg-transport-encrypt (IETF LC) 
	Document Shepherd: David

    Drafts beyond WGLC:
    draft-ietf-tsvwg-ecn-encap-guidelines (Revised I-D Needed) 
	Document Shepherd: David
    draft-ietf-tsvwg-rfc6040update-shim (Revised I-D Needed) 
	Document Shepherd: David

    Chairs: Milestone updates
    WBA Liaison Request
    3GPP Liaison on DTLS/SCTP

    Liaisons received, watch list for updates and details on responses from chairs.

A WBA liaison relates to QoS across WiFi and 5G.
A 3GPP liaison relates to the presentation in this session on DTLS over SCTP 
bis (item 4.2 on agenda)

A slide on MP-DCCP was shown, since there was not time in the agenda
for a presentation.  The authors are asking for working group adoption. 
WG chairs will follow up with authors.

Chairs will ask for additional meeting time next time.

    Chairs: Announcements and Heads-Up
    Work related to other WGs:
    draft-ietf-tram-stun-pmtud - see TRAM WG, a new draft is expected after IETF-110.
    APN - Individual draft presented in other WGs.
    New work:
    draft-custura-tsvwg-dscp-considerations - Please read and comment on list.
    draft-jones-tsvwg-transport-for-satellite - See individual drafts.
    Active drafts:
    draft-fairhurst-tsvwg-cc
    draft-amend-tsvwg-multipath-dccp - See authors
    draft-lencse-tsvwg-mpt - Concerns Multipath
    draft-fairhurst-tsvwg-udp-options-dplpmtud - Progress depends on UDP-O

    SCTP WG Drafts
    4.1 Michael Tuexen: bis update to SCTP Spec. - WGLC
    draft-ietf-tsvwg-rfc4960-bis

David asked if there is anything covering all Path MTU topics?

Michael indicated that the SCTP Path MTU material is clarifying 
the application of existing techniques, no new protocol functionality 
is involved besides using DPLPMTUD.

Gorry asked about implementations: are these using the new spec as it stands?
Michael said most he knew were tracking the new standard.

David asked for other people to enlist as reviewers. Magnus and Gorry raised 
hands. Other reviewers are very welcome. Gorry will work with Michael to find 
committed last call reviewers to plan a WGLC on the next version (-10) of 
this draft, which was submitted shortly after the meeting.

The SCTP-NAT ID (post WGLC) has AD review comments and these will be sent to 
the list. Martin will take-over as AD for this work.

4.2 Magnus Westerlund: RFC6083.bis - Individual Draft
draft-westerlund-tsvwg-dtls-over-sctp-bis

3GPP have asked to resolve some issues with sending >16KB DTLS protected 
user messages over SCTP, which is not supported by RFC 6083.

Reason for this change is that DTLS record size is currently limited 
to 2^14-1 bytes and RFC 6083 specifies that only a single DTLS record 
per user message. And what is really needed is something that allows 
transmission of larger user messages that are protected by DTLS.

Gorry agrees he sees this as within the scope of the WG and asked if there 
are others with interest or expertise to work on this?

    Hannu Flink
    David Black
    Farni Boten

Expect adoption call for this draft on the list sometime soon.

    Transport WG Drafts: Protocols
    5.1 Joe Touch (proxy/remote): UDP Options
    draft-ietf-tsvwg-udp-options

Gorry stood in for Joe and reviewed the change summary.

There are open questions on what MSS might mean for UDP that bear 
discussion on the list: does it refer to maximum fragment size or 
maximum reassembled fragment size? It could be left as-is or warrant 
having 2 MSS options with different semantics.

Reviews from people from other areas (like APPS, or DNS groups) highly 
encouraged. David made a note for chairs to request early review in 
appropriate areas, particularly INT Area to ensure that a DNS expert 
looks at this for possible use with DNS (DNSSEC can generate 
large UDP datagrams).

Please violunteer to review the next version:
C. Heard plans to review the document (needs to be presented with a deadline).

5.2 Greg White: Identifying and Handling Non-Queue Building Flows
draft-ietf-tsvwg-nqb

Greg reviewed the last update. Time today needed to discuss the 
request for two DSCPs.

Draft is recommending DSCP 42 in end-networks to get the desired behavior 
on WiFi, and DSCP 2 remapping inside provider networks to survive 
interconnection (given aggregation & bleaching), then remapping back 
to 42 at edge.

All work to be done on this draft from last IETF meeting is done.

After Ana's measurement data, we will come back to the questions of using 
the two DSCPs and then WGLC.

5.3 Ana Custura: Measurements for DSCP 0x02 in an IXP - For Info
(presentation relating to draft-ietf-tsvwg-nqb, no draft)

DSCP 2 is a common marking as seen within the core - due to remarking 
pathologies.

David suggested that NQB might be possible to carry as EF in edge 
networks if it can be assured that it does not build queues. 
Greg pointed out that EF is traditionally prioritized while NQB 
is not, so this may not be what we want to recommend in considering 
future WiFi QoS.

Vidhi Goel asked if the recommendation is for the edge to map 
42 to 2 rather than bleached to zero? ISP safeguards are recommended. 
David pointed out risk of existing backbone/core traffic using 2 
being remarked to 42 at edge.

Possibility of an interim that might settle this topic, if needed.

Ana pointed out that protections against queue-building by NQB 
traffic in ISP network are needed anyways, so perhaps 42 and 2 are 
sufficient as a pair.

Ruediger Geib: we need to look carefuly how this will be carried in 
MPLS and other networks.

    Other Individual Drafts

Reordered in Agenda: Tom jones

Tom Jones - draft-jones-tsvwg-transport-for-satellite

Tom introduced this new draft. Asking for input on what to talk 
about in updating the prior guidance, especially regarding LEO 
and MEO satellites.

6.1 Robin Marx: Qlog for IETF Transports
draft-marx-qlog-main-schema

Robin reviewed Qlog and wide deployment support for QUIC. 
Would like to expand for other transports.

Martin Duke encouraged people considering applicability in the near 
term and would consider the core schema being worked outside of QUIC 
if there is a lot of immediate interest, otherwise it will continue 
being progressed in QUIC WG.

Initial work on Qlog will take place in the QUIC WG.

Phillip Hallam-Baker
In chat: To extend on what I just said, consider the case where we 
might want to manage a cluster of Web servers running QUIC 
(and other stuff). Having a standard format allowing a server to 
say "I am 90% loaded right now" would be a necessary part of that. 
And isn't that also the sort of thing you want to put in a log from 
time to time? Measuring the state of the server is 95% of that 
problem, and it is essentially logging. And that is the reason we 
need a file format because it might be a wire format at some point.

6.2 Pete Heist: ECN Deployment Observations
draft-heist-tsvwg-ecn-deployment-observations
- Measurement data presented in MAPRG at IETF-110.

Jon Morton is continuing this discussion from a prior 
presentation Pete gave in MAPRG.

Gorry asked how much data that they've gathered is applicable to 
other networks. Jon answered that script could probably be adapted 
to gather data for other vantage points. Pete said this can be 
run on Linux, and is available. This data was collected over 
3 weeks, but at a small installation ~800.

Jon started his additional presentation slides.

Bob disagreed with applying this analysis (audio was difficult to 
understand). We think he would like to understand the extent to 
which this problem is or could be present without L4S.

Discussion on L4S topics to be continued in next session on Wednesday.


15:30-16:30 Wednesday Session II ( 1 hour )
7. Transport WG Drafts: ECN
7.1 Agenda Recap (10 mins)

Agenda bash - Koen is also a presenter for item 7.3, second set of 
slides has been added to meeting materials

Chairs: L4S Drafts: What needs to be done

        Transport-protocol-independent requirements to use L4S service
        Safety of Internet-wide L4S experiment
    Criteria: WG "rough consensus" that each goal has been reached

Bob asked for clarification about his question on the list. 
David clarified that what is described here is what is expected. 
Multiple transport protocol implementations interoperating with 
network are not required.

Koen will present on implementations and plans.

Jake Holland asked about #2 (safety). David answered that the WGLC 
does not need to be held up on the other drafts if the ops draft 
still has some work needing to be done.
Jake suggests normative references to the ops drafts in the protocol 
specifications. If the WG does need normative language for describing 
operational constraints this will be done. 
According to Gorry, the informational status of the ops draft 
will not prevent the WG from making any RFC2119 requirements that 
are needed - possibly in other documents.

7.2 Greg White: L4S Operational Guidance - Adoption Request by authors

 draft-white-tsvwg-l4sops

Poll: How many people have read the ops draft (in one of the versions)?

    Raise hand: 17 (+1 in chat: Spencer Dawkins)
    Do not raise hand: 27
    Participants: 86

The draft may be ready for review by people with operational background.

WG adoption is in progress on the list

Jonathan Morton disagrees with the statement on long-lived flows. 
There will be a follow-up on the mailing list.

Poll: Should this ID be a basis for a WG item in TSVWG?

    Raise hand: 25
    Do not raise hand: 1
    Participants: 89

The sense in the (virtual) room is to adopt the document, the working 
group will continue a formal adoption call on list.

7.3 Koen De Schepper / Bob Briscoe: L4S ECN drafts

 draft-ietf-tsvwg-ecn-l4s-id
 draft-ietf-tsvwg-l4s-arch
 draft-ietf-tsvwg-aqm-dualq-coupled

Koen presents the Prague requirements survey regarding 
draft-ietf-tsvwg-ecn-l4s-id

Strong objections from implementers to documentation-only requirements.
An alternative approach in the draft would be to encourage documentation.

Text on scaling down to fractional congestion window needs further 
refinement.

Discussion on detection of non-L4S AQMs.

Jonathan Morton notes that the references mostly point to Bob's older 
papers. There are newer ones. This needs to be discussed in more detail.

The deployment experience should be better explained.

More clarification needed regarding the wording on compliance. 
There is already an ongoing terminology discussion on the list.

David suggests using a precise term for not behaving badly 
towards Reno-like traffic and adding one or two well-known 
examples that don't have Reno's long RTT behavior as further 
explanation.

Gorry suggests to avoid details of specific congestion control 
algorithms (e.g., details of how they interact with Reno).

Vidhi Goel asks about fairness to Reno.

Koen explains that existing TCP Prague implementations are 
compatible to Reno on packet drops. The requirements do not 
mandate the same response like Reno. There may be room for 
further improvement in other experiments.

Bob presents very briefly a status update of the L4S drafts.

8. All Other Business

 Ingemar Johansson: L4S in 5G 
 (presentation relating to draft-ietf-tsvwg-l4s-arch, no draft)

Presented after the official end time

Link to full document on this topic:
https://www.divaportal.org/smash/record.jsf?pid=diva2%3A1484466&dswid=9083