TSVWG Meeting at IETF 95, Buenos Aires WG Chairs: Gorry Fairhurst and David Black (remote) assisted by Martin Stiemerling ---- TSVWG Session 1 14:00-16:00 Tuesday Afternoon session I Note Taker 1: Fred Baker Notes updated by audio record. RFC Editor and IESG status: RFC Editor: AUTH48 draft-ietf-tsvwg-sctp-failover RFC-EDITOR draft-ietf-tsvwg-behave-requirements-update Approved-announcement to be sent draft-ietf-tsvwg-circuit-breaker In Last Call draft-ietf-tsvwg-rtcweb-qos Publication Requested draft-ietf-tsvwg-rfc5405bis In WG Last Call draft-ietf-tsvwg-gre-in-udp-encap (extended for 2 weeks to allow reviews to complete). draft-ietf-tsvwg-circuit-breaker Gorry (as author) Comments have been incorporated and the change to RFC2119 keywords have been sent to the list. Now to be sent to RFC Editor. draft-ietf-tsvwg-rtcweb-qos Updates to be completed after WGLC. draft-ietf-tsvwg-gre-in-udp-encap Lucy Intention is to get some reviews to close the WGLC. No additional comments. Three people have volunteered to review within a 2 week extension to the WGLC: - Donald E - Martin Stiemerling - Elliot Lear Reviews need to be sent to the mailing list. draft-ietf-tsvwg-sctp-ndata Michael The document should be ready for WGLC in the next revision, in 2 weeks. How many people in the room have read this document? (4+remote people). Two people have volunteered to review: - Fred Baker - Randall Jessup (offer remote) - Karen Nielson (offer via email) draft-morand-tsvwg-sctp-parameters-update Lionel Use of Diameter over SCTP. An errata will be submitted to ensure people know of the update, this may be a suitable editorial clarification. The AD can then decide on how to progress. Text will also be contributed to the planned update to RFC4960. draft-tuexen-tsvwg-rfc4960-errata Michael How many had read the latest version? (4) Previous meetings had also reviewed this. The open issues were reviewed. Please hum if you would support doing this work in TSVWG? (hum heard) Please hum if you have concerns about doing this work (or about starting this work at this time)? (no hum heard) Recommended for working group status, to be verified by an adoption call on the list. draft-ietf-tsvwg-natsupp Michael TSV started work on NAT for SCTP in the BEHAVE WG and transferred this work here after that group closed. No concerns were raised with publishing a NAT document, authors encouraged to complete the work and revise the ID. This will complete by the milestone. draft-tuexen-tsvwg-sctp-udp-encaps-cons Michael Documents issues now understood with the original RFC. This is a new draft, please read and comment on the list. The authors have been suggested to make a .bis document. Gorry: Do RFCs rely on the UDP encaps document? Michael: Currently no other RFCs would need to be updated if this document changes. Gorry: Is this something the WG should do as a WG... please consider and read the document. draft-ietf-tsvwg-diffserv-intercon (Gorry proxy for editors) No new issues have been found and a revised ID is being prepared. The ID is expected to proceed to WGLC after the IETF meeting. Two people have volunteered to review during WGLC: - Fred Baker - Robin There was a notice about up-coming ACCORD BOF on Thursday. ---- TSVWG Session 2 16:20-17:20 Wednesday Afternoon session II Note Taker: Natasha Rooney Notes updated by audio record. 7. Agenda Recap 8. WG Transport Encaps Drafts 8.1 Bob Briscoe - Guidelines for adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines (actually presented later in the meeting) Bob Briscoe Presents Purpose of this draft slide Liaisons with other groups (layer 2 mostly) Recent Activity slide SDOs and groups were identified, we read specs and drafted a response. 3GPP liaison: context slide We think there may be confusion here. ENodeB (base station) is the context. 3GPP references to ECN These specs reference ECN. Nearly of these are about ECN/RDP/UDP, these were fine. RAN references were more problematic. ECN in 3GPP ... slide Not spoken to 3GPP about this yet. Two issues: [1] talking about doing ECN on a node which isn't IP aware. Should be clearer. [2] marking behaviour is unclear. Gorry: so this is why we're writing this document! #1 ECN... slide No spec refers to RFC6040, there must be tunnel nodes, but RFC6040 is not clear on how it covers GDP so perhaps we need to do something here. Implementation seems unclear. We will put this into a formal liaison. Martin: Is the work just on the radio part? (Bob: Yes). Dirk Mayar: The 3GPP people would thank for the work you did here! Kevin Smith: Could this help scale things for ConEx? Bob: This would have same issues, and we do not plan to extend the scope of this particular document to cover this. #2 ECN...slide Constraint on the behaviour is not specified. ECN support in TRILL Draft is in WGLC List of ideas how to support ECN in TRILL. The approach work well because TRILL has been designed with forward compatibility in mind. Updating Tunnel Specs slide Scope was IP / IP Tunnels, did not cater for an IP Tunnel with a shim between which can not exist independently. We wanted to extend scope to cover these cases, we should update for this. Gorry: We should be careful to add this to the tunnels recommendations! Erik: We could add a paragraph to routing tunnels ID on the behaviour we want. Bob: We can only specify how we propagate info between GDP and IP, as the issue is vendor / machine specific. Gorry: Yes, please write up as a separate piece of text, so this can be added. Next Steps Chair Recommendation Gorry: The intention was to help people understand how to design things in the way we recommend. Please read the drafts and comment if these seem ready to publish. Is the advice in this draft being taken-up or appropriate? If this is, I’d encourage us to finish this document. Bob will reply to the liaison, and update the draft and write-up a short ID in 1.5 months. 9. Individual Drafts 9.1 Tim Szigeti - Mapping to 802.11 draft-szigeti-tsvwg-ieee-802-11 WG Adoption was requested Fred Baker presents Changes from -00 to -01 Normalising between this RFC and RFC 4594, specifically on diffserv code points Question for the group: is this new text ok? (see slides) Gorry: This draft has been around for some time... It has been presented several times. It seems within the Charter. Please hum if you would support doing this work in tsvwg?(hum heard) Please hum if you have concerns about doing this work (or about starting this work at this time)? (no hum heard) Gorry: I will take this to the list and we will start an adoption call on the list at the IETF. If there is adoption, we expect to also ask immediately for people to review this draft. 9.2 Bob Briscoe - Identifying Modified ECN Semantics for Ultra-Low Queuing Delay draft-briscoe-tsvwg-ecn-l4s-id-00 (actually presented later in the meeting) Bob Presents Low Latency slide... Recap on data centre TCP demo at IETF93 3 parts to standardise draft We need to look at thing to classify on, looking at a type of ECN. Choice of identifier slide We picked the one with the most green boxes! Meaning... slide proposing: new service, not update to 3168. Get rid of square root in the original 3168. If we choose ECT... slide Intended status slide experimental at the moment, would like a discussion on list for it to move to proposed standard. Next Steps slide It has been quiet since so we assume everyone agrees! Gorry: You can't really assume that! Gorry: So please do discuss this draft on the list. 9.3. Michael Welzl - TCP Alternative Backoff with ECN (ABE) draft-khademi-alternativebackoff-ecn Gorry (as Chair): This draft was brought to tsvwg after consultation about which working group is most appropriate to discuss this draft as an update to RFC3168. Michael Presents Context slide Proposal is to update ECN, particular the congestion response MUST be the same as for a single dropped packet. New text in red on the slide Motivation slide This rule prevents us from using the knowledge which AQM gives us ABE: draft history slide Question slide Questions Michael: Is there interest in adopting an updated draft that updates the RFC3168 rule? Bob Briscoe: Would you be opposed to adding something more to RFC3168? E.g., allowing control packets to be updated by ECN? Michael: Not against this in principle, it depends on how much work is needed. Gorry: Depends on the maturity of those contributions. Brian: I support this. Is the PS update just to remove those constraints? Michael: Yes Brian: What is the status of the second document? Michael: Not informational, could be EXP. Brian: please go ahead and get this done. I’m skeptical if we say that we have to delay to include lots of other things, we could update other aspects in another update when we are ready. I support this. Erik: Why can you not do both updates in one document. If you are an implementor it would be easier to have all in one document. Michael: This split is the approach that the ADs advised this week. Martin Stiemerling (as AD): The second document is intended to define one experimental value. Martin (proxy for Dave Taht via Jabber): Can we look at the scope of loss and ECN marks within one RTT in this document? Michael: are we talking about responding to multiple marks in an RTT? Martin: Yes. Michael: ... in this case that’s something different. Markku Kojo: Is there enough experimentation to make this a PS immediately. There are things that can go wrong. There could be flight size errors, and issues in fast recovery, when flight size does not reflect the current pipe. RFC3168 works fine. A second issue is that small windows may not reduce a full MSS. Markku Kojo: I have a suggestion: make the reduction of at least one MSS. Gorry: I see the need to discuss this. Can we get evidence of a safe reduction? (Do you think this is something to measure, or something that we need to make an engineering decision upon?) to decide. Markku Kojo: Not sure on the approach. Gorry (Chair): We need to able to know an algorithm is safe, and I think we need to consider this. Markku Kojo: Let’s look at specific cases. Gorry: Can people comment on whether we do this? Mirja: Is this small window reduction also the same for non-ECN? Is this something for loss and ECN? Markku: This would be new for both cases? Bob: Stating one number may be too specific. Should be flexible. Gorry (Chair): We cannot do an adoption call today. I would like to know whether this is something that this WG needs to consider. Bob: The origins of the RFC3168 text were to try to be safe. I have not thought how to write this text. I support the PS not setting a specific value. Fred Baker: At the IETF-94 Bar BoF discussed an alternative proposal, I think someone had IPR. Michael: This draft does not have known IPR. Bob: The IPR has not been declared, but does not relate to this update. Brian: The "New Draft Text" slide is a good start. Needs some number checking on the number ranges, but this can be changed. Gorry: OK, the more energy to get the details correct. Mirja: Not sure about the text, I agree with Bob. I don’t know whether the RFC needs to be updated. Gorry: The proposal is to update the draft. Is changing 0.5 to 0.7 “essentially” the same. Mirja: I’m just not sure how we correct we can get this new text. Chair Recommendation Gorry: As Chair, I note that people are interested in this. We should find text for the document that clarifies the intent. Please resubmit the draft and then we can discuss whether to make it a working group draft, or some other outcome for the text. Please also split-out the recommended value document. Mirja: I agree. Please work on this. I would also like more discussion, if we can’t agree on the details then clearly the WG won’t publish something (personal opinion). Martin: I agree we should encourage people to take this forward. Decision: Michael will revise and issue 2 drafts in the next 1-2 months. Thanks for the final meeting slide Bob!