Datagram Congestion Control Protocol (DCCP) WG IETF-72, Dublin, Ireland WG Chairs: Thomas Phelan Gorry Fairhurst jabber: dccp@jabber.ietf.org Note-taker at IETF-72: Jukka MJ Manner 1. Agenda - Gorry Fairhurst Colin Perkins: I spoke to the author of TFRC/RTP. She is no longer working on the topic. Gorry: We will expect this draft to go dormant, and remove this from the agenda for the next meeting. 2. Document Status - Gorry Fairhurst Some documents had been published, others were in RFC Ed queue (see slides). It was expected there would soon be two more drafts in WGLC. Lars Eggert: Note the milestone for QS is experimental. Gorry: Yes, as in Charter. (This is now this is also fixed on the slide.) 3. Active WG Drafts * DCCP Service Codes - Gorry Fairhurst (as author) http://www.ietf.org/internet-drafts/draft-ietf-dccp-serv-codes-06.txt Gorry: Are we ready for a WGLC of the SC draft? Lars: I think it is ready. There is a section on IPsec and how the service codes operate with IPsec. Do we need service codes in the IPsec selectors? Gorry: SC could be a selector for connections, not packets (as normal in IPsec SPD). This makes life harder for IPsec. Lars: We need to talk with the ipsecme people, eg. Tero Kivinen (?). Tom: Do we need to resolve that, then go for WGLC? Lars: You may start a WGLC and keep the IPsec comment as a first WGLC comment. Gorry: OK. We will start this straight after the IETF, Tom will Shepherd. * Faster Restart for TFRC http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-05.txt This was not presented. There were no questions. * DCCP CCID4: TFRC with Small Packets http://www.ietf.org/internet-drafts/draft-ietf-ccid4-02.txt This was not presented. Gorry: Has anyone read a recent version, are you happy with it? Lars: I am happy. Tom: Is there anyone to review the Spec in detail? This will need some review before going to WGLC. We will take this to the list, to see if people have feedback (e.g. implementors). * DCCP Simultaneous-Open Technique - Gorry Fairhurst (as author) http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-01.txt Colin: I am not sure we should recommend the use of options on a DCCP Listen packet, but agree that there must not be a payload. Gorry: We need to give guidance. There are good reasons why a payload is bad (no sequence numbers, undetermined CCID, options, etc). There does not seem to be a technical reason why one could not invent an option that was useful to announce on a Listen Packet, but we do not specify one. Colin: This could be used in future to carry a nonce to assist a firewall. Gorry: Yes, possible. Colin: I would choose language carefully, it may be better to leave this open. Gorry: Offers to help get this wording correct are welcome. Gorry: Are we otherwise finished? Do we need to ask for a DCCP packet type allocation from IANA? Colin: AVT has specified types in WG I-Ds by specifying a code-point when near WGLC, and noting in the I-D that the actual value will be confirmed by IANA on publication. Lars: It is OK to do what Colin suggested, and then you are basically done. Tom: Do we want to find a committed reviewer or go directly to WGLC? Remi: I am interesting in seeing information about an API for this, since it is a new method, but I understand it is not normal to publish API specs at the IETF. Some words would be useful. Gorry: OK. I also suggest we ask someone from the BEHAVE WG to review. [This is a normative reference in draft-ietf-behave-dccp] Lars: I agree, it needs to get some review. Colin: I have read it, and think it is good. * Quick-Start for DCCP - Gorry Fairhurst/A. Sathiaseelan http://www.ietf.org/internet-drafts/draft-ietf-dccp-quickstart-00.txt This was a new WG draft. Gorry: The new draft rearranges the language to explicitly mention the path-change case, and aligns to RFC 3448.bis. Lars: Doing QuickStart following path changes is interesting. His research group has done something in this area and found some problems identifying what to do when large numbers of requests were generated. It seems reasonable to randomise the behaviour, but this can not completely solve the synchronisation problem. Gorry: We agree. We chose 6 seconds as a reasonable starting point. Lars: It may be worth adding text to say if you encounter large numbers of downstream hosts. Gorry: Yes, that could be done. I think the risk is less for QS than for an algorithm that directly changes the congestion control. Overloaded QS routers will ignore extra requests, rather than overload the network. Gorry: Who has read the most recent draft of the I-D? Answer: Only Tom Phelan & authors. Tom: The spec is basically the same as the TCP version, updated to address issues in RFC4782 that are more relevant to TFRC. We need people to review this, the authors think it is done. 4. DCCP I-Ds in other WGs * BEHAVE for DCCP - Remi Denis http://www.ietf.org/internet-drafts/draft-ietf-behave-dccp-01.txt Tom Phelan: I have a concern with the statement that NATs "MUST NOT" implement ALG. Remi: This was discussed in a previous meeting, you can send comments. Tom: BEHAVE will start a WGLC soon. Can you please ensure the WGLC announcement is cross-posted to the DCCP list, too. * TSVWG for Ports and Service Codes. http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-iana-ports-00.txt Lars: Not a lot has happened. We took Gorry's text from the SC draft, and put it as an appendix. We will work on integrating this in the next revision. 5. Individual Submissions * Sender RTT Option - Gerrit Renker, presented by Chair http://www.ietf.org/internet-drafts/draft-renker-dccp-tfrc-rtt-option-00.txt This was a new individual draft. Tom: Who has read it? Answer: no one? Lars: If this fixes a weakness sin CCID-3, why should you not always use it? (i.e. make this a PS). Gorry: Variable paths and rates are a case where you might consider this, but there are places were CCID-3 will give similar results. I expect the author would agree to making this a required update to CCID-3, if the WG wishes. Lars: The approach seems like a good idea. We need some data before this could be accepted as a draft for the standards track. Are there cases were this is needed? Are there any cases where this could go wrong? Are there new security considerations: Is there a way to fool the recipient? Gorry: There are man-in-the-moddle attacks, but not sure this is much different to any other CC mechanism, you can do some horrible things if you know sequence numbers. Tom: We need to talk about these security considerations and uses of the option. Are there cases were you can fool the sender into sending more? Gorry: Yes, but not a special vulnerability. The main uses will be CCID-3 and CCID-4 where this gives benefit. There may be merit in making this a generic DCCP option (valuable for future CCIDs). It would be interesting to receive feedback on this. Gorry: Gerrit is looking for feedback, and others of co-authors. This comes from implementation experience, he is not necessarily wanting to pursue writing the Spec. * DCCP/UDP - Tom Phelan (as author) http://www.ietf.org/internet-drafts/draft-phelan-dccp-natencap-00.txt Colin: UDP encapsulation requires a change to the signaling for the stream, that will need to be addressed. How do you signal for this? Tom: This is not yet considered. 6. Implementor Feedback Tom: The user-space implementation was progressing. He had implemented CCID-3. - : The was work on a user-space port of DCCP for Windows 2K/XP/vista, 70-80% of the problems were Windows-specific. Gorry for Gerrit Renker et al: Linux implementation was considered stable, with testing of a range of network and application behaviours. This revealed a lot of implementation corner cases. Addressing these has resulted in a much more robust implementation, especially for CCID-3. Jukka Manner: We have worked on CCID-4, and understanding which CCID to use for VoIP. The answer for a home DSL environment in these experiments was to use CCID-3, not CCID-4. James: It would be good to have feedback on DCCP requirements for setting filters in home gateways, based on a draft "ietf-v6ops-cpe-simple-security". Would the DCCP group please comment? Gorry: This sounds like an excellent idea to get something right for DCCP. Please read and comment. Lars: What is the overall status of implementations? Gorry: From where I stand the Linux port looks stable and mature. This is quite a different story from a year ago. End of DCCP meeting. Minutes updated 19th August 2008.