Transport and Services WG, IETF-92 =================================================================== TSVWG Meeting Part 1, Tuesday, March 24, 1520-1720 in Parisian Room. WG Chairs: Gorry Fairhurst and David Black Note Taker: Fred Baker 1. Agenda - see slides (No changes to the final agenda) 2. Status/updates (WG Chairs) - draft-ietf-tsvwg-behave-requirements-update NAT Behavioral Requirements Updates - draft-ietf-tsvwg-natsupp SCTP Network Address Translation Support - draft-ietf-tsvwg-rsvp-app-id-vv-profiles RSVP Application-ID Profiles for Voice and Video Streams - draft-ietf-tsvwg-rtcweb-qos DSCP and other packet markings for RTCWeb QoS - draft-ietf-tsvwg-sctp-dtls-encaps DTLS Encapsulation of SCTP Packets - draft-ietf-tsvwg-sctp-prpolicies Additional Policies for the PR Extension of SCTP Presentation - see the slides. ------------- 2. Recommendations for Transport Port Number Uses draft-ietf-tsvwg-port-use Presenter: Chairs on behalf of Joe Touch Update from IESG Evaluation and discussion of open issues. Questions were taken on the new text, but no additional comments were received. Scott Bradner: How many ports per protocol (secure and insecure, or just one port)? - What was the conclusion? David Black: The security area has no overall recommendation for one port vs. two. This depends on the protocol. Transport port conservation makes a recommendation that one port is generally preferable, but it depends on the protocol specifics. Scott: One port can be hard to police for security. David: That point was noted in discussion w/the IESG, but was one of many. David reviewed section 7.4 and indicated the new proposed text. ?: A client can request security, but the server is not, configured - this results in no security, a problem. David: If two ports helps in this case, the case could be made. Gorry: Is this text helpful? Scott: This makes two contradictory statements. David: It is no worse than the first case. Fred: It seems like the justification needs to focus on having a insecure port at all. Gorry: Yes, that was stated in the draft earlier, so this is the part that describes what happens next. John Messenger: Is the word "simultaneously" correct, here? Scott: Why do you not you add a sentence that explicitly says try to use a secure port? [A: see above - lack of IETF security consensus.] Martin Stiemerling (as a port reviewer): The word "simultaneously" should go. If IANA sees two requests in succession, they would see this and react accordingly. Gorry: Yes, IANA has a memory! I suggest we remove this. David: Are there any additional comments? [Hum taken is for text as presented with the word "simultaneously" removed.] Gorry: Hum if this text represents good text for this document? (Strong hum for; No hum for people who think more work is needed. ------------- 3. Encapsulation Considerations draft-rtg-dt-encap Presenter: Erik Nordmark This draft is the result of a Routing Area design team looking at proposed new encapsulations across multiple IETF WGs (bier, nvo3, sfc). David: Be careful about sending back information (e.g. ICMP) to a source, and then seeing this discarded - one-way tunnels, sending from within tunnels, ECMP. ?: Also note that multiple headers can remove the source info. Erik: The cases do not expect unlimited encapsulations. David: Think of test networks, multiple tunnels will happen soon. Bob Briscoe: Nobody controls how many encamps have happened before the ingress. Erik: You control the MTU at the start of the underlay. Matt: Congestion control is not a requirement. What is needed is that the efficiency does not drop. It is easy to construct applications that contribute to congestion collapse. Even using TCP such applications can be made - congestion-controlled traffic can still be dangerous. Erik: I can see this - we looked at the other end of the spectrum where apps may carry Ethernet packets with no known CC. David: The circuit breaker draft may be applicable, which can offer a level of policing to protect to overload. Martin (transport AD): Thanks for this activity to document. Is there an explicit assumption this all runs in a well-managed underlay - I would like to see this stated explicitly in the document. This makes a big difference. Gorry: Did you talk about protection from off-path attacks? Erik: Yes. Spencer (transport AD): I think this is important for more than pseudo-wires, it also interacts with circuit breakers. If you had sequence numbers of some sort, you could do much more than you can at the moment. Erik: In the OAM context, this would not need to be enabled all the time, so that may not be so useful for a CB. Gorry: There are other things you could add that record stats from time to time to enable CB processing. Erik: Yes, this came up. We talked about a marker bit that could help with this. David: Yes, there needs to be some data from ingress to egress or vice-versa that allows you to figure out something is wrong. Erik: We also need to figure out the strengths of recommendations. Gorry: What happens next? Erik: Please read the spec? We also want cross-pollination between the transport and routing areas. ------------- 4. Generic UDP Encapsulation for IP Tunneling draft-ietf-tsvwg-gre-in-udp-encap Presenter: Tom Herbert Work had built on the MPLS/UDP draft. GRE allows non-IP traffic, with recourse to careful provisioning, and some way to prevent use in the general Internet. Gorry Fairhurst (as an individual): So, there is a lot of GRE or enhanced GRE across the Internet, e.g., for VPNs. What are we trying to solve in this draft? Is it a general-purpose protocol stack that allows any GRE usage. David: Is your usage L2 or L3? (congestion controlled?) Gorry: I do both. Tom: We have lots of deployment of GRE over IP. When we put this over UDP, we may widen the scope of places that can use GRE, and that may change things. We hope most traffic is congestion-controlled. We could say non-IP is not allowed. Gorry: I think we need to see how much we want this to be usable, and this WG should help Tom if we need to do this. ?: What is the purpose in doing this rather than using GUE to carry GRE? Is it just to try to save bytes? Tom: I think this is a perfectly valid alternative. We do see a need to support GRE in data centres. It does not solve all encapsulated issues. We could encamps in something else. ?: We could use some extra protocol information to work through NATs. Martin: Are you expecting traffic to return on the same set of ports/addresses that need to be considered. This draft needs to work with NATs, and that also needs text since this can prevent ICMP messages returning. Tom: In IPv6 you could potentially use the flow label, and then you can set the src and dust ports in a more normal fashion. Erik: You could potentially use a different set of headers if you use the flow label. It is easier for an implementation to set some fields or not within the header, that is much better than optional headers. David: Please continue this on the lists. ------------- 5. Requirements and reference architecture for Mobile Throughput Guidance Exposure draft-sprecher-mobile-tg-exposure-req-arch Presenter: Nurit Sprecher Describes middle boxes inserted on path to content servers, by proposing changes to congestion control. This builds on capacity understanding at the last hop in a cellular network. Related draft: draft-flinck-mobile-throughput-guidance Mobile Throughput Guidance Inband Signaling Protocol Fred Baker: Have you looked at protocols such as RCP or XCP that were attempts to set the cwnd to an appropriate value. -: We did not look at these. Instead we looked at the cellular network. Gorry: There is experience with trying to use RCP to set the sending rate that may provide useful background. Bob: This is an important problem to try to solve. However, it worries me that you have not looked at prior work (including RCXP, XCP), but more importantly there is quite a lot of work with stability proofs about Internet methods such as TCP. Doing something like this in isolation, e.g., detecting loss on a backhaul, may result in huge loss or congestion somewhere else. Either whole network has to do something new, or you need to be very aware of the network-wide implications. -: We first looked at the radio bottleneck. Bob: Look to the network problem. Aaron: In 2001, we started an IETF WG called PILC that looked to address issues tworks. I suggest you look to this. I also ran a group that implemented XCP 9 or so years ago - one of the real challenges is identifying how to share the capacity among groups of flows sharing bottleneck capacity. There is a reason why slow-start starts slow. Kevin Smith: We really would like to tune the rate of a flow without encryption implications. We would welcome comments. Gorry: Is this something that should be introduced into TCP stacks in general, or just some types of TCP stack? Kevin: We look to the group for guidance. David Black (individual): +1 for Bob, Aaron. The problem is asymmetric - reducing capacity can be safe, whereas increasing may be much more significant. Another question is the scaling of this - e.g., what happens when I start using a new server, one that I have not previously communicated with. David (as Chair): The security of the middle box interaction is one of the topics for the SPUD BOF this IETF. Jana: There are specific situations that this solution seems to target. The requirements seem important to consider, this comes up multiple times at the IETF, we need to look at this. This all happens becomes TCP congestion control is imperfect - this is a hard problem - we need to get protocols deployed, and if we do not have good solutions this will keep coming back. Michael Scharf: There was an IRTF RFC written in response to the things we learned from QuickStart, XCP and RCP (RFC 6077). This enumerates some challenges that need to be met, and this will really help focus this sort of work. Gorry: I think the first thing to do is to identify the problem space and where candidates may exist to take forward. Aaron: There may be utility in telling it (safely) the maximum rate a path can support. Spencer: I chaired the TrigTran BoF a long time ago, and this has been controversial for some time. As AD I'd encourage you to not give up on the idea of doing work. Gorry: Please take the discussion to the list. We have not yet seen how this could be realised. I note that the ICCRG research group may be a good platform to present ideas for taking this forward, and you can bring proposals back to TSVWG. =================================================================== TSVWG Meeting Part 2, Thursday, March 26, 1300-1500 in Parisian Room. WG Chairs: Gorry Fairhurst and David Black Note Taker: David Borman 6. Agenda - see slides One item added on a draft in TCPM that applies also to SCTP. -------------------- 6.1 TCP and SCTP RTO Restart - API Considerations Presenter: Gorry Fairhurst/Anna Brunstrom Presentation - see the slides. The draft is approaching WGLC in the TCPM WG. There is a proposal is to add an Informative section to define the SCTP API. This was normal practice for SCTP drafts. This document will have a WGLC also in TSVWG. Any questions? None. Michael Tuexen: I have reviewed the text, and proposed text for this section. Karen Neilson: I have read the spec and will comment in WGLC. ---------- 7. UDP Usage Guidelines draft-ietf-tsvwg-rfc5405bis Presenter: Gorry Fairhurst (Editor) Presentation for -01 of the document, see the slides. An appendix was added because some people asked for information about UDP encapsulation for IPv6. A diffserv and multicast sections were added Authors think this is ready for WG last call. There is one update needed to add more on off-path data insertion attacks. David Black: How may have read this draft? (About 4) David Black: How many will read this if there is a WG last call? (About 12) David Black: We will start a WGLC for the next version, please comment on the list. ------------- 8. Stream Schedulers and User Message Interleaving for the Stream Control Transmission Protocol draft-ietf-tsvwg-sctp-ndata Presenter: Michal Tuexen Presentation - see the slides. SCTP has a SSN per stream, and this is not documented in the SCTP base spec. Michael proposes filing an Errata to RFC 4960 to correct this. Matt Mathis: 2^16-1 maximum value implies there is no built-in re-ordering protection times, should this be 2^15-1? Michael: Yes, but using the SCTP TSN gives the additional protection. Gorry: What is your intention and when will we receive the final version of this document? Michael: It will take about 2 months for a document that is complete. David: We would like to send to WGLC before Prague, since RTCweb is waiting on this. Gorry: We need reviewers, are there any volunteers? Karen: I appreciate the suggested solution, I appreciate the suggested solution. I will be a reviewer. Magnus: I will review too. -------------- 9. Quick Failover Algorithm in SCTP draft-ietf-tsvwg-sctp-failover Presenter: Karen Nielsen Presentation - see the slides. Gorry: We did a WG LC on -08 document, and had a few technical, points there was agreement on how to fix them. There is some editorial work needed to make sure it will pass IESG review. I see the RFC 2119 usage now looks good. Michael: If the heartbeat is not disabled by the user, then must send these faster. If not, then follow the user. If you make the text explicit, then OK. Michael: There is a change to the security model, it is not only faster, but with permanent failover, STCP moves the traffic away permanently from the first path if there is a traffic peak. Karen: The draft also proposes a mode with permanent switch over, we will document the changes and the security implications. Gorry: The security section was short, this should address that. The abstract should mention the API exists as a separate section. Karen: We received comments suggesting we remove the discussion of CC - since this document removes this. Gorry: I suggest you may leave the text marked "RFC Editor to Remove", so the IETF and IESG knows that CC changes were discussed, and that there was consensus that this change was agreed. David Black: Please change the lower-case "should" to an "ought to". Karen: We do not think this should update RFC 4960. Gorry: First, is implementation optional for a compliant SCTP stack? Karen: Yes, optional Gorry: Are you updating the base mechanisms that you expect base implementer to read this? Randal Stewart: You would not want to update RFC 4960, because that would make existing implementations non compliant. I do not think this document should update RFC 4960. David: Is there a hidden "SHOULD" here? Is the text clear that this is based on one way to implement RFC4960, but this builds on one specific way to do this. Randal: There are reasons that an implementation does not want the dormant state specified in the base spec. This is an implementation choice needed for this specific spec. Chairs: We seem to have agreement this will not update RFC 4960. Gorry: We should note this in the shepherd writeup. Gorry: I believe the standard language changes have been made, the rest is just editorial. We do not need to appoint reviewers for this, but we plan to start a short WG LC in May. ------------- 10. DiffServ interconnection classes and practice draft-itef-tsvwg-diffserv-intercon Presenter: David Black (Editor) Presentation - see the slides. David: There is a different in perspective between the discouragment in RFCs to change DSCPs within a network, rather than the conditioning expected at the edge of the networks. Bob Briscoe: I think this could confuse two issues, and this draft does not need to speak about changing DSCPs in the network. Although there is encouragement to not remark unknown DSCPs in the network, this is not common practice. Although there may be benefits (e.g. for tracing back where code points were sent). David: I think we agree on the edge focus. RFC 2475 is pretty clear what to do. Brian Carpenter: I think the language could be better, and phrasing does not contradict the other RFCs. David: MPLS-based interiors provide a strong motivation for what is being described. David: This is heading for an Informational RFC, WGLC after Prague. Bob: I think my main point is the draft talks about stuff that is not related to the main issue, and does not say enough about the core issues, where it could say more. If you change a DSCP to a common set on ingress and remap this back on an egress some technologies can cope with this. Matt Mathis: It was good to see this document emerge. I would like to raise what to do with unknown markings - specifically less than best effort. I think it would be good to explicitly describe support for Scavenger class, and not bleach this up to a BE codepoint. Brian: The RFCs state that CS1 is not a mappable class. Support for CS1 as Scavenger is dodgy within the network. Ted Hardy: What does dodgy mean? Brian: Within your network can do anything inside, interconnects are different. The description of Scavanger class is problematical in the current RFCs. Ted: Standard operating procedure can evolve over time, and there are transit networks that connect networks that support Scavenger class - it would be good not to bleach this to let people use this. Bob: I think it is not wise to bleach (remark as default, 00) at the edges. Gorry: Should this RFC say CS1 is not mapped here at an intercon? David: What do you wish the recommendation to say? Gorry: Should we say if an Interconnect does not support CS1 across the Internet, than drop this or remark this? Matt: I do not want it bleached back to a BE class. David: Operational practice seems inconsistent, and we could start a new draft? David: Practically, use of the class between domains is unreliable. Brian: The lower-level per domain (Scavenger) is informational and contradicts the standards-track usage for the CS values. Gorry: This is the correct WG to look at this issue, if people wish to see this. I think it should be a separate document. Matt Mathis: A part of the problem is there is so much conflicting language in this space, the learning curve is way too steep. David: I would like to see a separate document if we do this. Brian: The RFCs do not specify a DSCP for Scavenger, it suggests using CS1, which is in conflict with other usage. David: I would prefer to not to turn this into a standards track draft updating RFC 2474. If we need, please write a separate doc. Bob Briscoe: That is one reason I said everything in the RFCs is sufficient. That is why it is dangerous to bleach things you do not understand in the border. Ted: Brian is technically correct, but the discussion is about what people do on their networks, and people use CS1. So updating relevant standards track is useful. But we are asking how do we behave when we reach one of these things. We want Scavenger class where there is no Scavenger class on the network. David: We have done something like this before with CS6. If there is a desire to carry a CS without bleaching a tunnel may be needed. Gorry: Scavenger support document been discussed before, if there is renewed interest, then we should take it up again. As an individual contributor, I would be interested. If you are also interested in this topic, please talk to the WG chairs. Gorry: When will the WG interconnect document be ready? David: There will be a revised version by Prague. We will ask for WGLC after. Matt: A question: I dabble in this space. What is daunting is the large number of conflicting documents in various status of deployment. In TCPM there is a roadmap document about TCP. I have often wished for such a document here. It would be useful to have as an inventory. A wiki may more useful than an RFC perhaps? Bob: Note - the byte that Matt is referring to is 6 bits David: ECN has the other two bits Matt: No, I was referring to network support for all 8 bits. David: There's some useful diffserv intro material in the DART draft (draft-ietf-dart-dscp-rtp), in the RFC Editor Queue. -------- 11. Network Transport Circuit Breakers draft-ietf-tsvwg-circuit-breaker Presenter: Gorry Fairhurst (Editor) Presentation - see the slides Circuit breakers are to prevent congestion collapse, not to provide congestion control. The current draft expires soon, I will revise soon and ask for WGLC if we do not discover more things. Colin Perkins: I have read this, I think it is a good draft and I can review it again. I support it going forward. Arron Falk: I feel like experience would be helpful in understanding its usefulness. Is there interest by implementors? David: Colin has built one for RTP. An expired draft with pseudo-wire in title, also specified a circuit breaker. There is a latent spec. for a third, It is not unimplemented. Andrew: Google have been using all the types of circuit breakers in their B3 network. There was a recent ACM SIGCOM paper on the network that does not specifically talk about the design of circuit breakers, but does mention they were deployed and needed. David: Please send a link to the paper to the list. Tom Herbert: How does this relate to the UDP Circuit Breaker draft? In RFC 5405 it said must do CC. How do these relate? Gorry: If you have a feedback channel with more than 1 pkt per RTT, then the new version said you should do a circuit breaker, if you do not do congestion control. Tom: So this is not congestion control? Gorry: Indeed, this operates on a much longer timescale. Matt: There was a conversation over 10 years ago where it was recognized that there is a class of apps that sends way below the rate of TCP, and in that context, a circuit breaker can be really useful for other flows, and is more useful. David: Please read the 5405bis draft, which has text on that. Matt: The point is that for times of congestion control compliance, circuit breakers define the envelop of what we think is safe. Colin: For RTP this was the intention, and I think this is what I expected to see in the UDP Usage Guideline. Gorry: It would be good to check this was so, comments welcome. Please read the document and see if it says what is needed. I will revise and then ask for a WGLC. ---------------- 12. Guidelines for adding Congestion Notification to Protocols that Encapsulate IP draft-ietf-tsvwg-ecn-encap-guidelines Presenter: Bob Briscoe Presentation - see the slides. This is a BCP about propagating ECN from lower level protocols up into IP. There is a liaison agreement being prepared to ensure groups can contribute. A 3GPP liaison is being prepared. Trill is also discussing how to use these recommendations. David: Pat, can you say something about liaison with IEEE 802? Pat Thaler: Basically, there is no objection, but we are not doing any congestion work now. If we plan this, we expect we would take this into account in IEEE. Bob: We plan to publish this, and then later IEEE 802 can use it when they get to start their congestion work. David: If we get 3GPP inputs then this will be good. Bob: There is already work in 3GPP networks that conflicts with the IETF usage (to signal codec selection) and this is not the same as the IETF meaning and we plan to make the IETF intention clear in the next revision. It might become controversial, but we can deal with that. David: When do you intend to present for WGLC? Bob: July. Gorry: Can we also present the final document to INT area after this is finished? ----------------- 13. Tunnel Congestion Feedback draft-wei-tsvwg-tunnel-congestion-feedback Presenter: Chairs David: Are any authors in the room? No. Gorry: This has been discussed, let us talk about it anyway. David: It uses ECN to measure level of congestion in a tunnel, and then do something about it. David: I think this is more in circuit space. We can use this as a reference circuit breaker. Bob: I sent a huge review to TSVWG list. There is a lot to do to make this into a useful document. It does not currently consider loss (a previous issue). David: There are two problems: It assumes that everything we care about is in the ECN signal and it says you could do this and could do that, you want to have it say "do this". There needs to be a recommended method. Bob: It does not yet cover loss of ECN, which is important. David: There is work in progress, let us give it another cycle and see where it is like in July. ----------------- 14.1 Other comments: Eric Noordmark: The UDP usage document could be an IP usage document. Most of what is said applies to any usage of the network when there is no congestion control. I would not like people to think that doing things over IP directly is somehow different. Should we make a note of this in the present document? Or make another document that says to do everything in the UDP doc except ports? David: Int Area sounds good. Gorry: Please send an email about this. It would be good to follow-up in INT Area. A separate document would perhaps focus the right eyes onto it, could you ask what is the best way forward? Eric Noordmark: I will ask in the INT area. ------------ 14.2 New Work: SCTP Handshake Presenter: Michael Tuxen (no draft) The SCTP handshake uses a cookie-based procedure to protect against flooding attacks. The idea is to reconsider initialization using the cookies where you do not need this, e.g., usage over DTLS. The security properties also should be looked at to see if we can use a different protection. I am looking for interest from people. Richard Scheffenegger: Is this generic for SCTP or just over DTLS? Michael: Yes, since the cookie is generic. ?: Is the CPU usage a problem for the DOS attack, or in general Randall: There is no specification of how you process the cookie. It was never verified. BSD uses SHA-1. Some of this an artefact of the implementation choice, but I have no problem looking at this topic. Michael: The problem is that this needs to be stateless. Karen: What is the third leg of the exchange (in the slide)? Michael: I want it on the first leg without playing games. Michael: If you have any interest, drop me an email. Chairs: Take this to the list or send ---------- The meeting closed.