--------------------------------------------- tsvwg Session 1 (2:00:00) Tuesday Afternoon session I 13:30-15:30 Room Name: Park Ballroom I --------------------------------------------- tsvwg Session 2 (1:00:00) Wednesday Morning session II 11:10-12:10 Room Name: Grand Ballroom I --------------------------------------------- TSVWG Meeting at IETF 97, Seoul, South Korea --> Minutes [DRAFT] WG Chairs: Gorry Fairhurst and David Black Note Taker 1: Randy Stewart Note Taker 2: Vincent Roca Jabber Scribe: Tim Chown ---- Session 1 (100 min scheduled out of 120 min total) 1. Agenda 2. Status/updates (WG Chairs) (15 minutes) UDP Usage Guidelines draft-ietf-tsvwg-rfc5405bis --> Now in RFC Editor Queue DiffServ interconnection classes and practice draft-ietf-tsvwg-diffserv-intercon --> IESG telechat after Seoul, Dec 1 Tunnel Congestion Feedback draft-ietf-tsvwg-tunnel-congestion-feedback --> WG LC Complete, need two more reviews, Bob Briscoe and Jake Holland volunteered Guidelines for DiffServ to IEEE 802.11 Mapping draft-ietf-tsvwg-ieee-802-11-00 --> WG Last Call coming in December Charter & Milestones --> See slides for milestone updates New draft: ECN for Tunnels that use shim headers - new milestone: June (submit for RFC publication) New draft: SCTP (RFC 4960 Errata and Issues) - new milestone: September (submit for RFC publication) --> During the sessions in Seoul, the sense of the room was to adopt 4 more drafts - milestones will be added for each draft if/when adopted. 3. WG draft-to-be A Lower Effort Per-Hop Behavior (LE PHB) - David Black for Roland Bless (10 minutes) draft-ietf-tsvwg-le-phb-00 --> Draft now has correct name, is an adopted WG draft --> David Black (WG chair) suggests that this be standards track, and update RFC 4594 (Diffserv Service Classes), as work on the 802.11 Diffserv draft found some confusing text there that needs clarification, and also suggests that obsoleting RFC 3662 (Lower Effort PDB) is the right thing to do. Will be taken up on list. 4. L4S - Bob Briscoe (30 minutes) --> L4S work is expected to take place in TSVWG. Sense of room in Seoul is that the WG should adopt these drafts (no hums heard against adoption). The actual WG adoption call for these drafts on the mailing list is expected to follow the list adoption call for the ECN Experimentation draft (see item 5 below). Low Latency, Low Loss, Scalable Throughput (L4S) Internet Service: Architecture draft-briscoe-tsvwg-l4s-arch-00 DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput draft-briscoe-tsvwg-aqm-dualq-coupled-00 --> Overload options: a) Continue to mark, use tail-drop OR b) Switch to classic AQM drop Mirja (AD) suggests b), which preserves low latency when low latency queue is overloaded in contrast to a) which fills the queue. Results shown use drop in non-L4S queue. Have experimented with ECN there, no significant difference in results for drop/mark rate less than 25%. Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay draft-briscoe-tsvwg-ecn-l4s-id-02 --> If there are two or more bottlenecks, and any bottleneck other than the first is located at a dual queue node, this marking technique causes packet reordering for non-L4S traffic at any dual queue node that is a bottleneck, but not the first bottleneck because all because all CE-marked packets, including those for non-L4S-traffic, go through the low-latency L4S queue. 5. ECN-related drafts Explicit Congestion Notification (ECN) Experimentation - David Black (20 minutes) draft-black-tsvwg-ecn-experimentation --> Major open issue is whether ECT(1) codepoint usage outside of experiments should be strongly discouraged (SHOULD NOT use) or outright prohibited (MUST NOT use). The rough consensus in the room is for prohibition (MUST NOT use). This is reflected in the -04 version of the draft uploaded after the meeting, and discussion of this topic will continue on the list. --> Sense of the room is for WG adoption of this draft (no hums heard against adoption). Adoption will be handled via a formal adoption call on the list. Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines Propagating Explicit Congestion Notification Across IP Tunnel Headers Separated by a Shim draft-briscoe-tsvwg-rfc6040bis (NOW draft-ietf-tsvwg-rfc6040update-shim) --> Quick status update on both drafts. rfc6040bis draft has now been correctly renamed and is a WG draft. 6. Congestion control drafts (brief introductions only, additional discussion of one or both drafts may take place in the immediately-following ICCRG meeting) Circuit Breaker Assisted Congestion Control (CBACC) - Jake Holland (5 minutes) draft-jholland-cb-assisted-cc --> Problem: Malicious node joining multicast sessions can overload a bottleneck link, degrading service to other nodes. Problem must be solved in order to successfully deploy inter-AS (across multiple operators) multicast video service. --> Only a brief introduction in TSVWG, more discussion occurred in ICCRG Layer 3 Quantized Congestion Notification (L3QCN) - Yolanda Yu (5 minutes) draft-yu-tsvwg-l3qcn --> This draft received a longer discussion in TSVWG, and hence was not taken up in ICCRG. The draft proposes to extend Ethernet backwards congestion notification (QCN) over IP via encapsulation for delivery across IP connectivity between Ethernet domains. Important comments from discussion: - Draft is currently written for data center leaf/spine networks only. That's too narrow a scope for the IETF to consider, but the draft is applicable to other somewhat controlled networks, e.g., L3VPN. (David Black, WG chair, speaking as an individual) - OTOH, backwards congestion notification outside of a transport protocol session is not safe for the Internet in general because it's too easy for an attacker to spoof the congestion notification. (Bob Briscoe) - Ethernet backwards congestion notification (QCN) is not deployed/used much today, hence extending it over IP may not be useful (Pat Thaler, IEEE 802 First Vice Chair, speaking as an individual) -- Session 2 (45 minutes scheduled out of 60 total) Note Taker 1: Maxim Proshin Note Taker 2: Vincent Roca Jabber Scribe: Tim Chown Agenda recap (5 minutes) 7. SCTP-related drafts Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol draft-ietf-tsvwg-sctp-ndata --> Draft is complete, and will go to Working Group Last Call shortly after meeting Stream Control Transmission Protocol (SCTP) Network Address Translation Support draft-ietf-tsvwg-natsupp --> Now that the -ndata draft is complete, expect progress on this draft before next IETF meeting in Chicago. WG chairs would like to be able to hold WG Last Call on this draft before Chicago meeting week. Additional Considerations for UDP Encapsulation of SCTP draft-tuexen-tsvwg-sctp-udp-encaps-cons-01 --> This is next in line after SCTP NAT draft above. Hope to have an RFC 6951bis draft for the summer IETF meeting in Prague. RFC 4960 Errata and Issues - Maxim Proshin (10 minutes) draft-ietf-tsvwg-rfc4960-errata --> Lots of small items, mostly editorial, a few technical. All the details matter, so reviewers are wanted, and the authors are actively recruiting people to review. 8. Individual drafts Transport Options for UDP - David Black for Joe Touch (10 minutes) draft-touch-tsvwg-udp-options-03 --> Only two peole in Seoul have read this draft, so no adoption hum taken. --> Use of this mechanism to realize UDP-Lite with UDP protocol number could be interesting if that works in practice. --> Request to take measurements to figure out how well this works in the Internet in general (Lars Eggert). These would be at scale measurements to see how widely this works (or doesn't), see IRTF MAPRG. Forward Error Correction (FEC) Framework version 2 - Vincent Roca (10 minutes) draft-roca-tsvwg-fecframev2 --> Nobody has read this draft. --> Conclusion from discusion is to seriously rework the draft: just write an additional I-D that explains how to **extend** RFC 6363 to add convolution codes and explain what changes to RFC 6363 are necessary to enable that. The result should be a much shorter draft that will be easier to get people to read. There's no need to reproduce all of the text of RFC 6363 and obsolete RFC. This would become an additional RFC that will extend RFC 6363, and will have to be read in conjuction with RFC 6363. --> Authors have an implementation. An indpendently developed implementation by someone else (or more than one someone else) other than the authors is highly desirable.