IETF 91 - Honolulu, November 2014 TSVWG minutes - FINAL ------------------------------------ Note taker: Aaron Falk Session 1 -- Thursday, 0900-1130 in Coral 2 Topic: Agenda Review & Bash Topic: Accomplishments & Status (see slides) AD shaming of authors allowing working group IDs to expire Topic: Recommendations for Transport Port Uses (see slides) No discussion Topic: Stream Schedulers and New Data Chunk for SCTP (see slides) Some work to do. Not receiving any technical comments. Draft should be ready for WGLC by next IETF. Looking for suggestions of a better name than "New Data", e.g. "Interleaved Data". Topic: SCTP Tail Loss Recovery Enhancements (see slides) Want to supplement SCTP fast recovery to improve recovery latency where fast retransmit is not triggered. May also increase throughput. -01 draft available. Implementation exists and experiments & collaboration happening. Discussion (Alexander Zimmermann:) Fast recovery improvements, reordering detection from TCPM may be applicable to SCTP Yoshifumi: the mod in 6675 to sack is not very aggressive with the rescue retransmit since the cwnd would allow much more data to be sent Karen: 6675 is already more agressive in other aspects already before rescue retransmit. Alex: Are you planning to apply this to TCP as well? Karen: no reason not to. Yoshifumi: Will you drive these changes to TCP? Karen: Google is already doing a good job for TCP. This is the principle of what Google is proposing for TCP with RACK David: "spurious cwnd halving if TLPP is re-ordered with subsequently sent packets (as SACKed)" is a good reason to discourage reordering in SCTP (as noted in draft-ietf-dart-dscp-rtp). Gorry (via jabber): I like this work, and think we should get updates as this work progresses - in the end we need to consider make a conscious decision if this looks to be proposing something different to what happens in TCP (future check) Michael Tuxen: I like this work, too. I is not only useful in signalling networks, but also for RTCWeb. Karen: plan to continue work on individual draft, then submit as wg item. Topic: draft-geib-tsvwg-diffserv-intercon David Black has joined Ruediger Geib as a co-author. Spencer Dawkins (AD) will run process. MPLS pen-ultimate hop [label] hopping results in traffic class label being removed before tunnel egress - major motivation for this draft Goal is enabling interconnection between networks where only a small number of traffic classes are used. Targeting Informational RFC, looking for comments and working group adoption. Discussion ** Hum in favor of adopting draft. No opposition - confirm on list. ** Topic: Network Transport Circuit Breakers David: how many folks have read the draft? About half-dozen in room. Who is willing to commit to sending review comments on list? David, Greg Shepherd, Lei. Are there any other scenarios the draft should be covering? (please respond on list) Discussion Tom Herbert, Google: is there data on how this interacts with the congestion control of other traffic? Gorry: The circuit breaker should act over longer timescales than TCP - response time measured in seconds, many many seconds. David: Could this draft be a BCP? Spencer (after discussion): Yes, BCP for protocol design is fine and has been done before. David: we'll probably need some worked examples for a BCP. Tom: is the point of this to satisfy the congestion control requirement for UDP tunnels? David: this is tied into other topics on the agenda. We're talking more about congestion considerations than congestion control. Tom: have a data center using TCP and everything is good. When other non-TCP traffic is injected (or even traffic w/a different TCP congestion control implementation), a lot of tuning is required. Like the idea of the circuit breaker. Martin: motivation is to mitigate damage to other peoples traffic if you run UDP without congestion control. Traffic engineering is not going to be sufficient in all cases. Darrel Lewis, Cisco: Thinking about LISP. Applauding conceptual effort. It's only sane and obvious to have this capability. LISP has 3 mechanisms that look like circuit breakers. See RFC6830 (sec 4.2). Observation: also seeing well-behaved traffic within tunnels and have been looking at using ECN to deal with congestion. Topic: Tunnel Congestion Feedback (Xingpeng Wei) Chairs are interested in this topic because it may lead to a solution to an important problem - this looks like it could become a specification of a tunnel circuit breaker that other drafts could reuse by reference. (See slides) Designing a mechanism for network-based congestion control in tunnels. Tunnel egress monitors congestion and feeds back to tunnel ingress via IPFIX. Draft has been revised to clarify some things in response to wg comments. Asking for working group adoption. Discussion [A lengthy discussion ensured - minutes summarize important points only] Tunnel ingress/encapsulator is expected to respond to congestion reports (e.g., via shaping). This is not specified in the draft, and needs to be in order to have a complete solution. There could be more than one posisble response. This mechanism is complementary to end-to-end congestion control, and should operate on longer timescales to give end-to-end congestion control the first opportunity to respond (and trigger may likewise be less sensitive than end-to-end congestion control). It's circuit-breaker-like, but not on/off like a circuit breaker. Specification philosophy: Make mechanism available in implementations, use is operator's decision. There are other responses that operators could employ, e.g., add capacity, reroute traffic, and they need to be allowed. If using ECN in outer header when inner is not ECN capable, CE at egress currently should result in packet drop. There's some ECN-related material in RFC 6830. Standardization likely to be split - do overall solution here, any specific IPFIX changes or additions in a separate draft (but it's not clear whetehr any IPFIX work is needed). OPEN ISSUE *1: Should ECN indications (CE) be treated as equivalent to drops? This also came up in AQM. This is primarily about endpoint (or tunnel egress) reaction to CE. OPEN ISSUE *2: What should be done when not all nodes between tunnel ingress and egress are ECN-capable (and drop instead) or when an ECN-capable node is pushed too hard and starts dropping? -- Next steps (process handled by Spencer Dawkins [AD]) Spencer: Who has read the draft? about 7 Spencer: Is this a promising line of inquiry? about 7 (incl jabber) Spencer: anybody think the wg should not go this way? none Draft will remain in tsvwg WG, but not yet ready to adopt. Need to complete solution (see above on need to specify ingress response or possible responses) OPEN ISSUE *1 on ECN drop equivalence: Needs email discussion across tsvwg and aqm WGs. Martin Stiemerling (AD): need to distinguish between signalling mechanism and what is being signalled. Definitely break draft into pieces. IPFIX changes (if needed) should be in a separate draft so we can ask for early review from IPFIX Directorate. Standardization goal: subsequent folks doing UDP tunnels don't have to go through a lot of work to deal with congestion considerations. We could also put some fairly tight applicability restrictions on this mechanism, e.g., "must only be used within a single service provider's network" (see draft-ietf-mpls-in-udp for complete version). Spencer Dawkins: agree, we aren't limited to only standardize things that work in the open Internet so long as there are good applicability statements. Bob Briscoe will work with authors on revising draft for Dallas, could be adopted earlier if WG decised (via email and/or virtual interim meeting) that it's ready. TSVWG minutes Note taker: Joel Halpern Session 2 -- Thursday, 1p-3p in Coral 1 Topic: Return to Circuit Breaker topic from 1st sesion (with slides this time) Help sought from the working group with sections 4 and 5. Volunteer Please. Topic: UDP Usage Guidelines This draft is proposed for adoption as a WG draft. About 7 people in the room have read the draft ** Moderate hum in favor of adoption, silence against, will reconfirm adoption on the list. ** Topic: GRE in UDP Since Toronto, a design team has formed which has been addressing Congestion Considerations and UDP zero-checksum in IPv6 for both MPLS-in-UDP and GRE-in-UDP. Showed presentation that was given to MPLS WG on MPLS-in-UDP, as that was successful on Monday and the work is closely related, although the GRE-in-UDP draft has a broader scope and different mechanisms. One example of the parallelism is that the MPLS-in-UDP draft calls for checking the top MPLS label upon decap if there was a zero checksum. Corresponding GRE-in-UDP check would likely involve the GRE key field. Discussion of whether the assumption that by default / usually IP traffic is congestion controlled is a fair assumption. That is the current state of Internet traffic. GRE-in-UDP: design team still working on text. Paper submitted to IAB SEMI workshop on design team's experience - this took too much work, won't scale to likely increased use of UDP encap. Example - although there is an existing RFC on when UDP zerro checksum is ok to use with IPv6, that RFC is very hard to actually use / apply. Q: Is it acceptable to the WG to prohibit zero checksums for GRE in UDP with IPv6? In particular, is it acceptable from an implementation and deployment point of view? A: ** Based on discussion in room, answer is "no" ** - there was no rough consensus that such a prohibition would be acceptable, therefore the design team needs to continue work on when zero UDP checksums are ok to use with IPv6. Q: Given that GRE in UDP may be going through middleboxes, should this work take that into account? A: Design team will take a look, ask for input on list. The AD (Spencer Dawkins) asks what the list of issues and list of work to be done really is. Do we need separate documents for each tunnel that might want to use UDP? Chair hopes that the WG and other parts of the IETF community will work towards and find a more general solution. Many Thanks to the design team (David Black, Ross Callon, Gorry Fairhurst, Xiaohu Xu, Lucy Yong) for doing a lot more work than anticipated when they signed up to work on this. Topic: Diffserv and WebRTC This is related to the DART work to address multiple "streams" over the same5-tuple with different treatment needs. This draft is on mapping from the internal browser interface to the diffserve code point in the packet. This draft will need more work. Watch this space. Topic: General Transport Topics Remaining time in meeting used for general discussion of other Transport issues, as TSVAREA meeting was cancelled in Honolulu. Dan Wing: How would I find out what PHBs are available on a network I have joined, what DSCPs do I use, and how do I get authorization? Some folks offer this over HTTP, but that is a limited solution. And what about both ends of the communication? This seems to be analogous to the network signon browser redirects, which is being worked in OPS. This may also be related to service discovery. It may also cross many IETF area boundaries. Suggested to contact the IESG. Spencer Dawkins discussed IESG and Nomcom planning. Spencer has submitted a draft (draft-dawkins-iesg-one-or-more) increasing the IESG flexibility on the number of ADs for an area (from one-or-two to one-or-more). Please provide input to Nomcom early and often.