TSVWG Meeting IETF-80,Grand Ballroom, Prague Hilton 0900-1130 Thursday, March 31st, 2011 WG Chairs: James Polk Gorry Fairhurst Audio: Channel 5. Document Status and Accomplishments Status was reviewed by Chairs, the socket API for SCTP completed WGLC and James is still to do the write-up. SCTP Stream Reset is still in the WGLC state being discussed. There would be an update on port-srv at the end of the meeting. IETF TSVWG Documents * Source Quench draft-ietf-tsvwg-source-quench-00.txt - Discussion of document status Scott Bradner: A quick read of the source quench document says both "you may respond" and "you must not respond" in two different places, this should be clarified. There is cure text saying that source quench is not supported in IPv6. It is not accidental that source quench is missing from IPv6, this should be reworded. Scott Brim: When you use SHOULD, you are supposed to explain under what condition you should not do this, this is missing Anantha Ramaiah: It does not explain the issue on what the issue is with using source quench in a host. This needs a paragraph. Bob Briscoe: There was a long email from 12 years ago that explains this, I can send a reference this. This can be discussed on the list, and then can be added to motivate the case. James Polk: It is widely known that SQ is a bad idea, but the document should say this. Conclusion: This will need to be discussed on the mailing list and we can circulate this for the author to pick-up what is needed. * Bob/Jukka - Byte and Packet Congestion Notification draft-ietf-tsvwg-byte-pkt-congest-04 - Comments had been received and a new version was being prepared. Bob: The authors of the draft concerning ECN in RTP did not follow the guidance in this draft for specific reasons. We will clarify the recommendations and say where it is harmful. Colin: RTP has to respond in terms of packets by design, and consistency with the goals of RTP was considered better. RTP only reports the number of packets lost. It would make sense to me to say about protocols that do not support reporting in bytes. Magnus Westerland: Translation that uses proportional marking could mark by bytes, but otherwise it's not possible. Bob: We mostly meant this as guidance for new transports, rather than advice for modification of existing transports. Colin: This just needs clarification of cases were you do not need to follow the SHOULD. * Randy Stewart - SCTP Reset draft-ietf-tsvwg-sctp-strrst-09 draft-stewart-tsvwg-reconfuse-sctp (not for publication) - This was being discussed on the list. There were no significant comments in the meeting, other than that last call is ongoing and 11 people are responding to the discussion on the list. Conclusion: There appears to be consensus emerging, there needs to be discussion on whether it is viable to have one in-band mechanism. To resolve this, the WG needs to decide but there needs to be only one mechanism. * Randy Stewart - SCTP Network Address Translation Support draft-ietf-tsvwg-natsupp-00 - This needs WG feedback, please read. * Randy - SCTP ECN - SCTP ECN will need to make sure the ECN mark works with multihoming, that requires order and bundling requirements with SACK. Conclusion: The document will be re-spun, probably by end of April. * Bob Briscoe - L2 ECN Guidelines (15 min) draft-briscoe-tsvwg-ecn-encap-guidelines - Guidelines for use of ECN in L3 IP-aware switches. Michael Welzl: I am concerned about the ECN semantics. In IP, a queue is growing and about to overflow, but if you have a link layer mark it is probably using it to take some action of its own. That may mean there is no longer queue growth at L2, and so the document should be careful to maintain the semantics. Bob: At the moment this is about the wire protocol, not behaviour? Michael: Are you not afraid that the ECN mark may cause double reactions: at TCP and in the lower-layer. ?: There are pseudowires crossing MPLS should probably add ECN support. I will read and comment on the document. Joe Touch: L2 and ECN interaction is a concern. Should L2 set the ECN bit? If it reacts to the bit, that is a different issue. I'm very concerned that a L3 switch sets the ECN bit. For debuggability and diagnostics, it is easier to know there is a router, which decrements the hop count is if you touch the ECN bit. ?: I can contribute some words on how to use these features. Randall Steward: Unlike Joe, I like the idea of L3 switches marking ECN, because many such switches do have queues that can overflow. Marking is good when there is congestion. This helps deal with buffer bloat. Bob: The TTL function relates to routing and tools. Andrew: ECN is about crossing a congested queue, decrementing the TTL is about a routing decision. Joe: Is ECN about crossing an IP queue. We have to make very clear that when ECN is set, the congestion could be anywhere between two routers. This needs to somehow be reflected in the interpretation of the network performance when you see ECN marks. Randall: Documenting it is a very good idea. The unusual thing is there is no input queue, only an output queue. ?: The slides mentioned GTP in 3 GPPP. GTP was supported in release 9. Are you going to suggest marking of the internal header? Bob: If the external header gets marked, it should get propagated to the internal at decapsulation. GTP code will have to do this. RFC 6040 specifies how. ?: If you want any near term deployment of ECN, then this draft is good guidance, and recommend the draft going forward. Conclusion: We note the interest, please continue this work. * Joe Touch - Recommendations for Transport Port Uses draft-touch-tsvwg-port-use-00 - Intended to be advice to protocol designers needing a port. How many people have looked at this document?: 5 Conclusion: We need comments. Joe would like a WG adoption call then. The Chairs would also consult ADs and gauge reaction from Apps Area. * James Polk - Integrated Services Extension to Allow Multiple TSPECs draft-polk-tsvwg-intserv-multiple-tspec-06 Roland Bless: We have similar functionality defined in RFC 5975, we have a range of TSPEC. This avoids the need for a list of multiple TSPEC, avoiding discreet sets of bandwidth. James: There are reasons for not doing ranges, because we want to indicate that we really have discrete possibilities for the applications that we discussed. Roland: That could be corrected, by the receiver. James: Yes, but it is inefficient to hold this bandwidth during setup. Bruce Davie: There is also the issue that you can not easily express ranges for multidimensional TSPECs. James: What do you prioritise?... average or peak rate? Burst size? There is no ordering. Bruce: Because TSPECs are multidimensional, you end up with a volume. Ken Calver: This is a process question. I thought the bar was set at 5 people to look at doc to adopt it in the WG. I am concerned about detailed reviews. Cycles may be limited and that other drafts do not also require five detailed reviews. Bob's draft for instance did not require this. Gorry: I can answer for the ECN draft first. This draft would not need detailed reviews, since we expect Bob to take feedback from this group and indirectly from the other standards bodies that will use the output. I am expecting there will be implementation experience and plenty of reviews as this progresses. Ken: The question is more about "review" versus "detailed review" and examine the need for the document, etc. I am more used to this in WGLC. This is a high level of review for adoption, lifting the bar rather high - is it the same for all drafts through this WG? Dave Harrington: We have a problem with RSVP because the community of users does not participate in the IETF, there are people who want the work done. That makes it hard for us to tell if something should be accepted. For other documents, the participants turn up. So should we decide that because people do not come, we do not do it in the IETF, or we can decide we need real feedback from the people who represent the community We rely on the RSVP directorate to represent the user community to tell if this document needs to be published and whether it is in good shape. We do not normally do that using detailed reviews when the community can speak for themselves. Bruce (chair or RSVP Directorate): I would like to suggest that the directorate can comment on the usefulness of the draft. For this draft, two members have done detailed reviews, and there are other reviewers lined-up who will do more reviews if this is adopted. 5 before adoption is a very high bar, 2 detailed reviews and 5 usefulness comments should be enough for adoption, and a further two non-directorate reviews have been promised. Gorry: My only additional requirement is that I want to know there are people who to continue supply the detailed reviews. I will ask the WG for adoption. Bruce: Ken and Francois have agreed to do this, I will review the version. Dave: Can you confirm if this is a general statement or whether these people will review this draft document in the future? Bruce: Yes, this specific document. Gorry: The number 5 was a guideline, we wanted to be sure there was sufficient review and the motivation for judging adoption. Scott Bradner: I have not done a detailed reviews, but I strongly believe this should be something we work on. It is disappointing that we need this level of special for RSVP-related documents, I do not think the lack of review is as bad as what Dave was saying. Bruce: There are 2 detailed reviews completed, 2 commitments for further detailed reviews, and an additional 2 directorate members giving light review. Dave: I will not oppose if the 4 directorate members commit to this. Guidelines were set because there were not reviews happening, and the chairs needed some help. We held a meeting to judge support from the wider community and saw good responses, but we have not seen the level of support we expected to progressing these drafts. Gorry: I've seen this draft presented at several IETFs, and this particular draft has also been subject of discussion at much earlier meetings. I've seen a detailed review (please put the name of the other reviewer in the nits) and I've seen promises here of 2 more. If we get 4 committed reviewers for this draft as it progresses, I would be happy to ask the WG if they would support this work. Hum for supporting this as a WG Item: no opposition, there is support for adoption. Conclusion: The chairs will approach the AD to examine if the Charter can be updated for this and take any call to the list. * James Polk - RSVP Application ID Profiles for Real-Time Classification (10 min) draft-polk-tsvwg-rsvp-app-id-vv-profiles (discussion) Diffserv code points are about network service classes, rather than applications. So, low latency or low jitter, rather than telephony. Joe: A DSCP sometimes means traffic class, but should never relate to an application. Scott Bradner: I agree, this is class of service not application. Joe: This should say there is a co-ordination issue to describe a class of traffic, do not use this to describe an application, such as VoIP. Bruce: The ship has already sailed on the point which Joe made. RFC 4594 describes a mapping from classes of applications to DSCPs. Joe: I suggest saying: "Any application that wants the same class that telephony requires, rather than explicitly saying this is the telephony code point". Do not refer to a DCSP as for one specific application. James: For many people, EF means "voice". I will tidy the language for the spec. Bruce: Is there a reason the DCLASS object does not do what you need? The RFC defines a format for transporting a DSCP, but does not tell how to you use it. James: The source can assign a DSCP, but that does not necessarily work in the destination domain, whereas if you use a descriptive string they can be translated per domain. ?: Make sure you do not fail in the same way as diffserv, but also does not try to standardise traffic classes end to end. If this becomes a standard, this will impact other SDOs. You seem to want to standardise classes end to end, but it is something different to standardise specific characteristics for a class. Bruce: You are leveraging RFC 4594 (as Informational). We did never officially standardise traffic classes, but this proposal gives us a naming. RSVP devices then can do what they think is sensible. James: That is what we were doing with a single string. Progress is that the label is delimited, and can therefore add local tokens to it. Scott Brim: Do you then standardise a mapping to RFC 4594? James: We want to standardise the top level, and some (9) second level. Scott: What does clearly define "each string" mean? Bruce: I think this means there will be well-known strings, and devices have (local) profiles attached to those strings. Rather than there being a standard way to queue that traffic, the string is a key into local configuration. Scott Bradner: This is a dictionary without definitions... known words, no specific definition of mapping. James: Correct, it does not change the way we configure a router. Gorry: What is the dependency with the work in the mmusic WG? James: To be presented tomorrow. Bruce: Even if the mmusic WG does not accept the draft there, this draft has value. James: It would be great to coordinate. Bruce: Exactly, but should that fail, this should still go ahead. Conclusion: We will look to see whether MMUSIC wishes to progress this and hence we need to coordinate. This is expected to generate comments on the draft. * Gorry Fairhurst - IPv6 UDP Checksum Considerations (10 min) draft-ietf-6man-udpzero - This draft is stable and is nearing WGLC, authors were waiting for the companion document to be be completed. Please comment. * Yoshifumi Nishida - SCTP Failover draft-nishida-tsvwg-sctp-failover - Accelerating failover switching to the secondary path. Anantha Ramaiah: When is the path error count incremented? Randall: Timeout, heartbeat, data not acknowledged (ECN does not count). There is also an association error count. The presentation is correct. Randall: One of things that Apps often do is to play with RTOMIN and RTOMAX, which can have downsides. This work has value even without CMT. It is a sender-side behaviour, so it has no interop issues. CMT can just use this work. I am all for this work. Randall: The dormant state is very undocumented, some implementations kill the association, some keep trying the path. So I am not in favour of PMR=0, but rather see this simple approach go forward. I think we should make this an RFC. How many people had read this draft?: 5 people. * Jana Iyengar - SCTP Multipath draft-tuexen-tsvwg-sctp-multipath-00 - Work hopes to become experimental specification. Ken: Along the same lines as mptcp, the value of this largely helps long-lived flows. Do you have an idea where this method starts to win? Jana: We have not yet shown where the win starts, but we are aware that you do not want to split short flows. mptcp are having the same discussion. The quick failover draft is also useful in its own right and the multipath SCTP authors can coordinate with this work and make sure it evolves in a consistent way. How many people had read this draft?: 5 people. James: I think I hear both documents do not contradict, and the authors need to coordinate to make sure that does not happen and the WG will arrive at one consistent solution for quick failover. Scott Brim: I want to encourage this. It is not clear when it will be useful, but when it is, it will be immediately useful right away. Conclusion: We need to take discussion on the two documents to the list. We would love to hear feedback. * Joe Touch - Ports and Services Registry draft-ietf-tsvwg-iana-ports - Summarised updates following the IETF LC and the IESG changes made before publication. ***********