Minutes IETF110: tsvwg
minutes-110-tsvwg-04
Meeting Minutes | Transport and Services Working Group (tsvwg) WG | |
---|---|---|
Date and time | 2021-03-08 16:00 | |
Title | Minutes IETF110: tsvwg | |
State | Active | |
Other versions | plain text | |
Last updated | 2021-03-23 |
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