Datagram Congestion Control Protocol (DCCP) WG 1300-1500 WEDNESDAY, December 5, 2007 IETF-70, Vancouver, Canada WG Chairs: Thomas Phelan Gorry Fairhurst jabber: DCCP@jabber.ietf.org Notes provided by David Borman, updated by audio record. 1. Agenda Bashing (10 minutes) - Chair * Agenda changes * Election of Scribe for Proceedings * Jabber Scribe 2. Document Status (5 minutes) - Chair * Milestones: New WG I-D: CCID-4 * Documents in Last Call: None. * Documents Completed Last Call: DTLS/DCCP * Documents in IESG/AD Review: None. * Documents in RFC Editor Queue: draft-ietf-DCCP-rtp-07.txt (REF) * Published RFCs in period: None. 3. New Proposed Work * BEHAVE for DCCP (Remi Denis, 15 min) - NEW (to be confirmed) http://www.ietf.org/internet-drafts/draft-denis-behave-nat-DCCP-00.txt (See slides from presentation) Remi: There are many things that need to be done, some are easier than others. Colin: The DCCP project has always been a long-term project, and we should do the right thing. Lars: Just publishing documents does not change the installed base. Vendors took a couple of years and many wrong guesses to get it right. We help them by saying "Here is a way to do it". It will not get out quickly, but also for SCTP, those buying the NAT have control over what protocols they need. Remi: There are dependencies on solution 1, so we need it anyway. Colin: This document should not even hint that tunneling is an option. Colin: You can tunnel, and NAT. Tom: You can encapsulate, which is not just tunneling. Coin: Yes, you could write DCCP over UDP. This is essentially a tunneling solution. Gorry: I am less opposed to writing about it (tunneling), but more opposed to publishing it as an IETF recommendation. Colin: In the long term, we do not want tunneling, so why specify it? Lars: Why is encapsulating DCCP any different than encapsulating any other protocol? We have documents for other protocols. This document is how to deal with DCCP (and SCTP): instructions to a willing NAT vendor and what they should do. Tom: Tunneling is different to the approach in running SST over UDP (presented in the tsvarea meeting). Gorry: You are suggesting using UDP as a shim layer between DCCP and IP? Gorry: If a NAT is just mapping addresses, why do they need to know what the content is? Colin: If it is just NAT, then it we are only talking about addresses. If it is a firewall, then the midbox might want to know about Service Codes, etc. Tom: The existing documents seem to be about NAT. Dan Wing: Most BEHAVE WG documents are about how NAT should handle TCP/UDP/etc. Some documents, STUN, etc, talk about how to get around a firewall. Lars: This type of work would go to the BEHAVE WG. Any review would need joint review and presentations. Gorry: This seems good: We understand DCCP, they understand NAT. Tom: So, Is the DCCP WG interested in this being a BEHAVE WG document? * DCCP Update for BEHAVE (Gorry Fairhurst, 10 min) - NEW http://www.ietf.org/internet-drafts/draft-fairhurst-DCCP-behave-update-01.txt (See slides) ... Gorry: When you send the DCCP-Request packet, you already have decided you are the client. With two "clients", one would later have to decide to be the server. This does not fit with the DCCP design. Tom: This mainly deals with when both server/client are behind firewalls, and the server has to punch its way out. Gorry: That was our starting point. ... Gorry: The DCCP-Listen packet is only sent by the server, clients ignore it. What needs to go into this packet? Is this the right thing to do? Do we send it just once, or do we have to repeat it? Colin: Can I address one of these Listen packets to my NAT? Tom: No, currently we do not know where the NAT is. Colin: Only works if the server knows where the client is. Otherwise, could send it to the NAT and have it open things up. Dan Wing: On the slide, A DCCP-Listen from B on the right, should be sent to the private address of NAT B. But then, what do we do with nested NATs? Dan: This is more or less what ICE does. I'm concerned about security. Gorry: The packet is directed to the recipient (client), so I do not see greater issues than will be exposed when the connection starts. Dan: This ties into Remi's document. Mark: A Firewall wants to know what we are trying to do, so it needs things like the Service Code. Can we add this to the Listen Packet? Gorry: Yes, good idea, we will add this in the next revision. Colin: I think this approach is good. I am tempted to say that we should keep that in mind, and worry about generalizing the signaling later. Dan: Between this, sending out a message saying "I am listening on a port", you may want to use a DCCP-Listen. It is pretty funky having the server send out the message... Gorry: ... this only happens when the server knows who the client is. Lars: If we try to talk to the NAT, this only works for DCCP. We should look at more general ways to say you are listening on a port that is independent of the transport protocol. One method that works for all transports would help more. Steve Casner: If you can manage without a pre-punched hole for TCP, why is it different for DCCP? Gorry: TCP has a simultaneous open, which DCCP does not. Steve Casner: Could we have configuration on the NAT, to say that this server is listening? Gorry: Yes, for a server offering a commercial service, but that may not be appropriate for peer-to-peer, e.g. where the server is my host at home. Tom: Yes, a DCCP server is not just a content server, one example may be a VoIP phone. Steve Casner: There is a problem of being able to get through, having incoming traffic come through the NAT, for TCP you either open a hole to the address, or do something else to get the TCP connection to work. Magnus: One question is what happens before this Listen is sent? You need to get both ends to agree to the addresses and ports, so you will need a signaling method. Tom: There are 3 documents we need: DCCP BEHAVE, support for DCCP simultaneous open, and ICE/TURN for discovering your public address. Lars: Here this NAT translates the DCCP data flow. We can live with simple signaling there. I think we should be cautious when adding other things, like how long to keep it open, etc. Gorry: Agree. Lars: I do not know where to stop, or where the sweet spot is. Anything more complex that only works for DCCP would eventually intersect with other more general things. If it is simple, NATs are more likely to deploy it, especially if it is similar to what it is doing for other protocols. Tom: We seem to have come to consensus here that it is a problem, but we have not come to consensus that we need to fix it. Magnus: You need to have your own mechanism, it is a "Chicken and Egg" problem for how to create connections. Magnus: Discovery techniques exist for certain application. If we want parity with UDP/TCP, need to have all the parts in place. Remi: We can not just drop this one and prioritize the BEHAVE one. You also will need some STUN way of discovering your IP. Colin: We absolutely need this. There might be some extensions, but we need it. Mark: If we just told both ends to lie about protocol, and say we are UDP, and then the right thing would happen. Gorry: Yes I realized that. A DCCP packet looks like UDP, except that it has the DCCP protocol number, and the UDP-Length has the wrong value. If one chose to send a UDP-port, many receivers would actually receive it, and NATs are likely to treat this as just UDP (and do the right thing). I'm not advocating this approach, just saying I have examined it. Alas not all receiver stacks for UDP will ignore the UDP Length. We discovered when implementing UDP-Lite that some implementations build the checksum using the IP length (which would be OK), and the other half use UDP the UDP Length (which would fail, because DCCP uses this field for something else. Gorry: Do we need this specification then in this WG? Colin: Yes. Dan: Yes, this is a good approach. But, a DCCP-Listen needs to be retransmitted, because it breaks if the Listen is lost. You have to have retransmission. Gorry: How long a retransmission? Lars: 3 seconds? Gorry: Maybe, sounds the right sort of value, but I wonder how many times you should do this. Tom: Can we Hum for accepting this as a Work Item? (hums) Against accepting (no hums). There is unanimous support to take it on. Dan: I expect the ADs to add Remi's document to BEHAVE. We might expect a separate ICE/SCTP and ICE/DCCP documents. This also does not really fall in this WG. Need to do signaling for DCCP over friendly NATs, as well as for DCCP tunneled over UDP for unfriendly NATs. Lars: Good point, pushing work in this space will require more effort than usual, because it will need work here, in BEHAVE, and MMUSIC. Who would actually have this commitment? We should not start it if we do not have cycles to complete it. Gorry: Are you asking for all 3, or just this? I could volunteer for this, but for ICE, I do not have the right skill set. Magnus: We can do this without thinking too much about ICE. Lars: Magnus has convinced me that the level of commitment for the initial work is something that we have. 4. Active WG Drafts * DTLS over DCCP (Tom Phelan, 10 min) - Post WGLC http://www.ietf.org/internet-drafts/draft-ietf-DCCP-DTLS-03.txt (see slides) Gorry: Can you say more about the 'SHOULD' that was updated? Tom: It was do not start your retransmit timer until the lower layer has sent the message (if you can get that info from the stack). Colin: If I understand the intent is to have different Service Codes for DTLS, and non-DTLS? Tom: If an application sometimes runs DTLS and sometimes not, use different Service Codes. Colin: Are we going to be recommending that people use different codes? The implication is that you may need more Service Codes for RTP. Gorry: I note Services Codes do not require publication of an RFC. Also you can not force people to use different Service Codes. Colin: It's not entirely clear that you should be recommending different Service Codes for RTP and RTP over DTLS. Tom: I thought it was your comments that suggested different codes? Colin: Could be, but let's get this right. Tom: It is likely that the middle box would like to treat non-secure and secure Service Codes differently. It is currently a MUST. Mark: I am not quite sure what the rational is for using different Service Codes. You could use a port to differentiate these. It just feels wrong. Gorry: We struggled with this in the past. Does secure voice require a different treatment? Tom: It is not a different service, but a firewall might want to treat it differently. Mark: Otherwise you mux some port when you switch on/off. This is a deviation from that convention, we need a good reason for doing something different. I think we should recommend a different port. Tom: Ports are equivalent to use of Service Codes in DCCP, not sure we should recommend a different port. Mark: How do you configure firewalls? I am not averse to registering more Service Codes, it just seems strange. Tom: TCP uses a different port, because it does not have Service Codes, we have Service Codes, and this is consistent. Mark: TCP muxes on ports to avoid surprise, we have Service Codes so we can mux on either. Do want to mux on a port or on a Service Code, which one? Colin: Do not some TCP apps have the ability to start unencrypted, and then Start-DTLS? Magnus: A Start-TLS is preferred over using different ports. Tom: If a mode of operation that is always in the clear, use one Service Code. If always DTLS, use another. Otherwise, use a mixed mode. Tom: TCP uses a different port, but does not have Service Codes. Mark: TCP muxes on ports to avoid surprise, we have Service Codes so we can mux on either one. We do want to mux on one or the other, but on which one? Colin: Some TCP applications have the ability to start unencrypted, and then start TLS? We should find out there, because that might change what we do here. Magnus: Start-TLS is preferred over using different ports. Tom: If a mode of operation that is always in clear, use one Service Code. If always DTLS, use another. Otherwise, use a mixed mode. Remi: HTTP does something specific for DNS. Tom: If the mode of operation starts in the clear, use one Service Code. If always DTLS, use another. Otherwise, use a mixed mode. Remi:... Tom: rev -04 is coming out soon. Those uncomfortable with the double Service Code should read it and comment on it. Colin: You can not tell from a port number if it is TLS or not. The same would be here. A Service Code & port. An application starts the TLS handshake. Maguns: We seem to be talking about something that is application dependent. If the application can not handle switching, it should use a separate code, and the WG should make a recommendation. Gorry: The recommendation is to use a Service Code to say that you "will not use DTLS with the application". Mark: Back to Colin, it is not the same. TCP has a byte stream, and you can identify before/after TLS. DCCP is not reliable, you do not have that point. Gorry: That is, if you switch DTLS, that is not reliable: the Service Code just denotes that you are allowed to use DTLS with this application. Tom: You can in theory send encrypted and then unencrypted and alternate. At application you can easily send one or the other, but they do not typically do that. Gorry: There has been major changes from the DTLS input, that we should now do another Last Call. Please submit a new revision and this will be followed by a short WGLC. * TCP Friendly Rate Control (RFC 4338.bis) (Sally Floyd, 10 min) http://www.ietf.org/internet-drafts/draft-ietf-DCCP-rfc3448bis-03.txt Sally: I am hoping for this to be in and out of WG Last Call by next meeting. (see slides) Sally: There is future work on congestion window validation - this should be put this in a separate short document, because it does not really fit into current 3448.bis. Mark: In general, you have to be careful with congestion window validation method. The path RTT can be short and then you can get bad interactions if the RTT is shorter than the transport scheduling process times. This is hard to do in simulations. Hence, I would agree not to put it in the main spec, because we do not yet fully understand the impact of the design choices. Sally: I agree. Can you send email to the list on this? Mark: Yes. Gorry: It is clear there are cases where you want to do it and that this work is needed to complete the spec. But, it is also clear that this is something we need to investigate, and that also need to look at what may be happening in the TCP world. I do not want to delay publication of 4338.bis, but I confirm we do have research on congestion window validation that would help clarify this in future. Lars: Is there an urgency to publishing 4338.bis? Sally: It has been around for a while, and people would like to implement this. Gorry: This ties up a range of issues form 3448, and implementors need a common document that they can work from, many of our other DCCP work items depend on RFC 3448 (and hence this). Lars: If we split this off, would this new work be Experimental? or Proposed Standard? Sally: We need to wait for simulations, we do not know. Lars: OK. Gorry: Who has read this? (5) Tom: Is this now ready to go to Last Call? Sally: Yes, I am ready to go right now. Lars: Not so many people who read it, so should have explicit reviewers appointed. Sally: We have had review comments. Gorry: Do we have offers of people able to do reviews? Lars: I volunteer Vladimir from Nokia for a detailed review. Arjuna (via jabber): I will review it too. Gorry: OK, then we do a revision if needed and then ask for reviews. I am also going to ask for author feedback from each of the authors before we proceed to a WGLC - we need to know they have all read this, agree to the detail and will participate in the WGLC * Faster Restart (Sally Floyd, 10 min) http://www.ietf.org/internet-drafts/draft-ietf-DCCP-TFRC-faster-restart-05.txt (see slides) ???: Is there a reason why the maximum amount that the sender can send after idle is twice the in initial rate? Sally: If you are just starting and know nothing, you can start at the initial sending rate. In this case, you know more. i.e., you know that in the past you were able to send more. Starting at 2x seems reasonable, more would be too aggressive. ???: Is this also a justification for quadrupling? Sally: If the simulations show starting at 4x is reasonable then we will do that. Or if 2x is not OK, things will be adjusted. Arjuna's job is to beat on this issue in simulations. Anyone else who wants to beat on it would be welcomed. Gorry: I would like to encourage others to also contribute to this simulation analysis, if they can. Please contact the authors. Sally: There will be a revised draft at the next IETF with more test results. * DCCP CCID4: TFRC with Small Packets (Sally Floyd, 15 min) - NEW WG http://www.ietf.org/internet-drafts/draft-ietf-ccid4-01.txt Sally: This is ready for WG last call. (see slides) Sally: It needs just a few people to read it carefully. Gorry: This is TFRC for "Small Packets". Is there a congestion control maximum packet size for CCID4? And is this fixed at a smaller size? Sally: There is a cost with TFRC-SP, it can send one packet each 10ms. This is only useful for less than 1500 B. At 800 B, you can send 2x a normal TFRC. We could put in additional restrictions. Gorry: I would like to understand this: 800 B at 10ms spacing is still an appreciable flow rate, over 500 kbps! I think we need to carefully consider this for CCID-4. Gorry: Who has read this? (few). This is a very easy read, please do read the next revision and send comments to the list. Gorry: This document refers to 3448, and 3448.bis as an update, I think that by the time this is WGLC'ed, 3448.bis will have been approved. Can we make this normative on 3448.bis? Gorry: We will start the review of this by sending out an email specifically asking implementors for feedback on this document. When we get that, we will know whether or not we are ready for WG Last Call. * Service Codes (Gorry Fairhurst, 10 min) http://www.ietf.org/internet-drafts/draft-ietf-DCCP-serv-codes-03.txt (see slides) The document is complete, all issues have been covered, apart from: A section on mapping a Service Code to a Port. Description of the IANA allocation rules. An API section (which he plans to delete). Gorry suggested a mapping for the Service Code to a port, using top 16K of ports using an XOR of the Service Code bytes and then an OR with 0xC000. Is this useful as one way to avoid having IANA need to register DCCP ports? Can we use a wider range than the top 16K of ports, given multiple Service Codes can be associated with a single port? Lars: One of the issues here is the firewalls might try to verify the use of Service Codes against the allocated ports. They may continue to assign special meanings to specific ports. It is not good to re-use existing allocated ports for new applications. Lars: One of the goals currently on-going in the transport area is that we are also trying to get port allocation similar or the same for all transport protocols: TCP, UDP, SCTP, etc. We'd like to be able to offer a common form for IANA requests, and these are moving towards "Expert Review Lite". We also want to align RFC 2780 with DCCP and SCTP. Mark's proposal changes that, this is not a technical objection, but it is a management issue in that we do not want to make another more differences in the allocation methods. Tom: Well-known ports in DCCP do not have to be unique. Lars: IANA does not have a way to get a string without a port. Stick in a line in the registry with an empty port. There is no Service Code line in the IANA registry. It is only in the free-form text section, which is not a distinguisher. Tom: With the introduction of Service Codes in DCCP, ports become a different animal than what they were before. Lars: The reality is that the IANA Ports registry works now. Colin: The IANA does not currently ask for Service Codes when allocating DCCP Ports. Lars: IANA has put the Service Code in the long description for port 9 (discard). Magnus: The interesting thing is when someone sends in a request for a port and a Service Code, and someone else asks for the same Port with a different Service Code. Tom: We have not resolved yet whether multiple applications can reserve the same well known port? Lars: If you say Application, do you mean Service Code user? (yes) Assuming you need a port and you have a Service Code, you need to do two registrations. Second guy wants same port, new Service Code. Gorry: This is specified in the latest revision of the I-D. Tom: How does someone lookup Service Code associated with a port? Gorry: This is a comment in the registry, just informative. Colin: The Ports Registry should specify Service Codes. Gorry: Yes. Magnus: You also have SRV record for this name. Colin: I will send email to the IANA. Gorry: This is not that hard, we just have to get it right. Magnus: We do have some issues because we are talking about independent registries: Service Codes, service names, and also a port number. Gorry: Should we write this up for discussion? Lars: Yes, please first send to the DCCP list. Tom: We have applications that want registered ports, we need something that describes how to get them. Other applications want Service Codes, need to document that. There is a class of applications that do not need ports or DNS SRV records, they might use the hash algorithm instead. Gorry: I think the API appendix is redundant now, the Service Code operation has been clarified in the document. We propose to delete it. In the future, someone may wish to write an API specification for DCCP (no objections from the meeting). * Media Guide (Tom Phelan, 10 min) http://www.ietf.org/internet-drafts/draft-ietf-DCCP-TFRC-media-02.txt There had been no work on this draft - inputs are welcome. 5. Implementor feedback (Arnaldo, Andrea, Ian, Gerrit, Others? 10 min) (see slides) Slides on Faster Restart Feedback: Sally: You need to implement X_recv_set. Colin: It is not that complicated, but the text may not be very clear. Lars: There is also on-going work to revise RFC 1323. David Borman: Yes, this is still in progress. Gorry: I am going to post the questions (in two parts) to the list, authors and others in the WG, please do respond. 6. Individual Submissions * Quick-Start for DCCP (Gorry Fairhurst, 10 min) - Ready for WGLC? http://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-qs-02.txt Gorry: We think this document is complete. (see slides) Tom: This is not a WG document yet, right? Sally: I read the old version. I like adopting it as a WG document. I like the idea of a WG Last Call. Sally: Quick-start is Experimental, not suggested for main implementations. There are some cases where you can get false indications of whether or not everything in the path supports QS. Lars: This document is borderline on whether or not is is within the scope of the WG. I fear that if we take on more documents, this would take away cycles from other documents. Will this make the already accepted WG items go slower? Gorry: No - we think it is ready for WGLC, and may be more conservative now than QS for TCP. Lars: Show that you can move something out of the WG before moving this in. Tom: We are moving a couple of things out for WGLC already. Lars: I need to see finished documents in my in-box. Gorry: Is this the WG where we would need to adopt this? Lars: It is on the border between this WG and TSV, the same people are involved in both WG. We should have broader consensus. I don't have technical issues, just management issues. Clear out other things, before taking this on. 7. Related documents from other IETF WGs: * TFRC/RTP (L. Gharai, presented by C Perkins, 5 min) http://www.ietf.org/internet-drafts/draft-ietf-avt-TFRC-profile-10.txt There is no new update to this draft. * SIP over DCCP (to be confirmed) http://www.ietf.org/internet-drafts/draft-jennings-sip-DTLS-04.txt Tom: This is actually SIP over DTLS. It was updated recently (in Oct) but still an individual draft. I sent an email, but no response. * GIST over DCCP (to be confirmed) http://www.ietf.org/internet-drafts/draft-manner-nsis-gist-DCCP-00.txt Tom: Lower layer signaling protocol for NSIS. The chances of this becoming a WG draft soon is pretty remote. Lars: NSIS got a much stronger version of the same statement. ----------------------------------------------------------------------------- Summary of status changes draft-ietf-DCCP-DTLS - new revision, to be followed by short WGLC. draft-ietf-DCCP-rfc3448bis - reviews needed & author feedback, then ready for WGLC. draft-ietf-ccid4 - revision needed, then reviews needed for WGLC. draft-fairhurst-DCCP-behave-update - proposed for WG I-D.