TSVWG at IETF 108
Tuesday, July 28 UTC 14:10-15:50 Tuesday Session III - Minutes
Primary notetaker: Michael Scharf michael.scharf@hs-esslingen.de
Jabber Scribe: Spencer Dawkins
Presented by David Black
RFC’s completed/in Queue:
Drafts beyond WGLC:
Many drafts related to TSVWG (see chair slide deck for full list).
Bob Biscoe (on jabber): There are two drafts related to Low Latency DOCSIS: One describes LLD, the other QProtection. Both with ISE.
Milestone updates
Greg White: NQB PHB now targets proposed standard.
David Black: Yes, we will fix this.
Gorry: UDP Options presentation should be moved to second meeting.
David: Data Center Congestion Control could be moved to the end of this session (not done, authors were not available on this short notice).
Martin Duke (on jabber): feedback on quic-natsupp should move to Thursday as something might come out of the QUIC WG meeting.
draft-ietf-tsvwg-rfc4960-bis
Adressing Gorry’s remaining comments.
Appendix A: ECN for SCTP
Authors do not think option 3 makes sense, the preference is option 1. What does the WG want?
Gorry: In a PS the language has be clear. My preference would be option 3 (if the text were correct). Does the WG think this is ready to standardise now? Has it been implemented?
Maksim: What will happen with assigned parameters?
David: Does this result in a normative reference?
Gorry: There has been lots of ECN discussion since this RFC4960, so an ID regarding ECN in SCTP would make sense. A milestone could be added, if the WG wants to do this.
Magnus (relaying a comment from Bob): “the curent text mimics RFC3168, which is being updated in TCPM by AccECN. So it would only make sense to include ECN in SCTP if it goes straight for more accuracy, as in QUIC and TCP.”
Gorry: The update to the SCTP.bis is due in about one month. Reviewers are needed. Authors will contact potential reviewers.
draft-ietf-tsvwg-natsupp
Maksim’s remaining comments
Mohamed’s comments regarding IP reassembly
Revision 20 has no TODOs any more
Gorry: The proposal is to start a 3-week WGLC by end of this week. Please read and review the document!
draft-ietf-tsvwg-nqb
Status
Common remarking policies/pathologies
David: The table (slide 3) is excellent. The row for CS5 is the most important one, as this also describes how equipment that classifies only on the 3 MSBs (“Precedence”) will treat traffic - group NQB traffic with CS5, VA (Voice-Admit) and EF (Expedited Forwarding) into single aggregate (same queue).
Draft discusses how NQB is treated in Wifi access points
Impact on higher layer protocols
Gorry: How significant is this issue if traffic fits into the NQB profile?
David: Some text should be added, e.g., “when used as intended, this should not be a problem for NQB traffic”. Any problems are likely to be caused by mis-marking queue-building traffic as NQB and/or problems in queue protection algorithm.
Greg: L4S may help provide early warning to a sender that traffic being sent NQB is actually building a queue (mark traffic with DSCP for NQB PHB and ECT(1) for L4S).
Gorry: Does the codepoint need to be allocated (provisionally)?
David: WGLC by end of this year is planned.
Martin D.: Can we document considerations on how not to use DSCP codepoints? E.g., be careful about DSCPs that could be remarked to the default DSCP for LE.
Gorry (as individual): We have a measurement tool that we used to analyze the LE PHB that we are currently using in 6man. Our research group would be interested in further DSCP measurements, and helping to write an ID. Volunteers are needed for hosting our new virtual version for the probe. If you are interested, contact Gorry.
TSWVG session 1 ends early!
Note takers: Brian Trammell and Jake Holland
meeting materials
draft-ietf-tsvwg-udp-options
Gorry: We have slides from Joe in the proceedings, I can talk to them.
Gorry: A new revision will be uploaded after the meeting, which may fix all remaining issues. Please read and provide comments.
draft-duke-quic-natsupp
Martin: I have taken this draft to QUIC, the new revision fixes editorial comments. It did not make it on to the QUIC agenda this time.
Gorry: This follows a long series of BEHAVE-like docs, we’d like to see updates presented here as you move forward.
Greg White: I just uploaded a first draft (https://tools.ietf.org/html/draft-white-tsvwg-l4sops-00) of an L4S Operational Guidance document inspired by Jake’s list. Have slides later.
Jonathon Morton: I’ve seen this draft and read it briefly. I notice that most options rely on operators that run RFC3168 bottlenecks becoming aware of L4S and changing their networks. I’m concerned about this.
Wes: The editors think it’s done. Please comment.
David Black: A related question on NQB PHB has to be answered there.
Bob Briscoe: Is policing mandatory in DiffServ?
David Black: In NQB context, it is necessary.
Bob Briscoe: But in an RFC 2474 etc, PHBs are normative, but policing etc is informational.
David Black: Do you need that functionality to deliver the behavior as specified?
terminological handshaking continues
Bob Briscoe: will take it to the list
Gorry Fairhust: RFC 2474 says “…may require…”
David Black: L4S LLQ is not a PHB. What tools does the operator need? Some of these might be answered in the experiment.
Bob Briscoe: The experiment is: is it possible to do this without per-flow behaviors? if these behaviors are mandatory, that’s kind of pointless.
David Black: A bad outcome would be, building long queues in the LLQ…
Bob Briscoe: Should be, if I behave then I get lower latency, and if not, I don’t, move to list.
David Black: Not that simple, wish it were.
Greg White: On NQB aspect, the intent is to flesh out the section on traffic protection as a SHOULD, explaining ramifications of not implementing. Ensuring NQB works well can be managed in a couple of different ways, traffic protection is one.
David Black: A discussion on operator alternatives without NQB in equipment might inform this discussion.
Bob Briscoe: In the arch ID, DQ aspect is designed to be simple enough to end up everywhere, not just bottlenecks. There, you don’t want queue protection. So this shouldn’t be mandatory, because sometimes it’s there just in case a node becomes a bottleneck.
David Black: This is a common design trope.
Explanations on slide 6
Issue 19 “Single codepoint for both low latency & resequencing tolerance”
Issue 20 “Objection to ECT(1) codepoint usage”
Issue 29 “classic bottleneck detection can misidentify L4S queues as RFC 3168 queues”
Wes: Please let us know on the list.
draft-ietf-tsvwg-ecn-l4s-id
draft-ietf-tsvwg-l4s-arch
draft-ietf-tsvwg-aqm-dualq-coupled
on slide 4
Jonathan Morton: Are you aware of Mohit Tahiliani’s effort on fqcodel for NS3?
Bob Briscoe: That’s what we’re talking about here. Mohit’s students are working on that, with Tom, and Tom has students as well.
on slide 7: SHOULD remain responsive at low RTT?
Gorry Fairhurst: Did this MUST come from the L4S work? I don’t see equivalent things in TCP requiring a MUST.
Bob Briscoe: No. Standard TCP’s queue is never this short. Only once the queue got this short did we notice this.
Mirja via Jabber: +1 to not-MUST (first one on slide 7)
Jonathan via Jabber: We should allow effective send rates to drop below 2RTT via pacing but keep cwind.
David Black: I would like to see the ICCRG discussion on this.
Bob: Please note this draft doesn’t exist yet. You can look at it if you want to go to GitHub and compile the XML.
David Black: Please take discussion on what’s normative/experimental/informational/etc into ICCRG.
Gorry: Opinions please: is this useful?
Jabber: 3 +1’s to useful from Martin, Jake, Philip.
Richard Scheffenegger: I believe having a protocol-independent CC defined on the standards track (initial experimental) makes more sense than an informational-only document.
Jana Iyengar: I should probably read the draft. I tend to agree this should be in ICCRG. Is this more of a framework than a congestion controller?
Bob: There’s a core, but it’s got some options.
Jana: Effectively componentized? Ok that makes sense.
Pete Heist (jabber): Please note that L4S and classic can also share a queue during hash collision in FQ.
Jonathan Morton (jabber): Also, this also happens if differences are hidden by a tunnel.
Bob: That’s not L4S specific, that’s a general FQ problem.
draft-pan-tsvwg-hpccplus
draft-dai-tsvwg-pfc-free-congestion-control
Richard Scheffeneger: Why do you see lower queue occupancy than dctcp?
Huichen: This is because it’s marking earlier.
Richard: like fluid-model?
Huichen: WE designed it from scratch, this might not be the same.
Bob: There have been some issues in the dctcp spec with pacing and ewma. L4S work has offered some patches, but they have declined so far, because this has deployed. L4S works with ramp or step, there’s likely some similarities.
David: The question is what should IETF do in this area? Both of these activities started from ROCEv2, but may be more broadly applicable?
Richard: I am a little unhappy about signaling overhead, but this is interesting work showing the benefits of proportional ecn marking. We should discuss more in iccrg?
Huichen: This is beyond experimental and engineering work in active deployments, I think it needs to be in TSVWGbecause of that.
Richard: The TSVWGscope is internet wide more than datacenter (ICCRG is scoped at coingestion control methods).
Magnus (as AD): WE have tried to do work understanding CC in iccrg. An algorithm write-up is more appropriate for iccrg, signaling and such are appropriate for tsvwg.
Lars: ROCE also presents an inter-SDO question. What would be result if the IETF published stuff about what ROCE should do? (Do these SDOs expect these specs to come from the IETF?) Why this not in Infiniband instead?
Huichen: We implemented our own UDP-based thing, we think there’s applicability in other cases, like we tried it in TCP and it worked fine.
Lars: If this is a general mechanism that applies elsewhere that’s fine. It is still important to understand if this will be deployed anywhere?
Huichen: There’s support for this in Broadcom and missing–Mellanox? NICs.
David: This is interesting to the extent it’s applicable to IETF protocols, but we’re not scoped for any ROCEv2 work here.
Magnus: If this could be written as generic congestion control that could be helpful.
Bob: Please note that if it’s done in IETF the work has to be open, whereas in infiniband maybe not.
Gorry: There are lots of interesting things to follow up, but we are out of time.