DCCP Thurs 21/10WG Chairs: Thomas Phelan Gorry Fairhurst jabber: dccp@jabber.ietf.org Note-taker at IETF-73: Ingemar Johansson Agenda: No comments, but Remi's presentation was moved forward before the Simultaneous Open I-D. The progress of the WG Last Calls since last meeting were reviewed. The Milestones were reviewed. Magnus reported that publication of draft-ietf-dccp-rtp-07.txt was waiting for authors to respond to AD comments on another document (this was in the RAI area). There were delays to CCDI-4 and "Faster Restart", but these were ac function of publishing RFC 3448.bis as RFC 5348. Progress was expected by the next IETF. * Service Codes(draft-ietf-dccp-serv-codes-08.txt). The had been useful comments in WGLC from various people and in particular from Eddie Kohler and Colin Perkins. -08 revision to be sent to AD's by Tom Phelan. * Behave DCCP (draft-ietf-behave-dccp-04.txt) This specified NAT traversal requirements for DCCP, presented by Remi Denis. The draft had passed WGLC, there had been comments from the AD, and the draft was being revised. There was one comment on managing NATs. L. Eggert: I suggest following up the comment on manageability, by saying that this was not a requirement in other documents in the same series. I believe this comment has been sorted out now. L. Eggert: BEHAVE are now taking on new work: This morning the agreed that TCP and UDP MUST be implemented to allow 6 to 4 networking. There is a question whether DCCP and SCTP SHOULD be implemented as a requirement in the new specifications. R. Dennis: DCCP is trivial, in that this has been defined and needs very little change. G.Fairhurst: We need to ensure this becomes a SHOULD in the I-D. L.Eggert: Please think about checking this discussion in BEHAVE and make sure that DCCP appears on this list. G.Fairhurst: This is a note to the WG, if you want this to happen be sure to make sure this is known in BEHAVE. * Simultaneous Open (draft-ietf-dccp-simul-open-05.txt). This was a small update to DCCP easier to use with NAT traversal. Gorry asked if we needed to update the document to allow data to be carried on a DCCP-Listen packet, but ignored on reception - as per other packet types. Gorry asked if anyone knew that this was a problem (i.e. even though a DCCP-Listen has no sequence numbers). Magnus W.: I guess it could be used as a sort of probe packet, but then you would like to see a response packet. M. Mathis: In TCP there is no way to do a SYN differently. If we allowed a SYN to have no data, would actually have made updating easier. Gorry said that there had been a suggestion to update the pseudococde. Are there opinions on this from the WG? - is it better to have pseudocode updates, or is it better not to have lots of changes in different documents? Magnus W.: I think we should look at how many changes are needed. T. Phelan: We should look at the changes, and tell the changes. G.Fairhurst: I think I will need help to make sure the pseudocode is good or to help write this. Magnus had proposed a DCCP-Request could be triggered when a Listen was received. T. Phelan: This is a big change, previously DCCP-Listen packets were ignored by the client. This allows them to cause a reaction, but it may be worth it. Magnus W.: This is a substantial optimization in reducing the establishment delay. The disadvantage is two extra packets. If you do an offer/answer, then the client will usually receive the DCCP-Listen first, and only send a response when you got the SIP answer. G.Fairhurst: The diagrams should be updated to reflect this. Magnus W.: Does the WG think this cost is worth the benefit? G.Fairhurst: OK, I will make a proposal with new text for the list to consider. The next step will be a revised I-D next week. I will also look at the pseudocode and include this if possible (or later to discuss via email). I will call the list on the pseudocode and then we need to make the decision on the safety of sending data. T. Phelan: We will then decide if we need another shorter WGLC. * TFRC Faster Restart (draft-ietf-dccp-tfrc-faster-restart-06.txt). An update was provided on current progress, the authors said that simulation work would be performed on this topic and promised an update for the next IETF. There were no questions or comments. * CCID-4 (draft-ietf-dccp-ccid4-02.txt) There was no presentation for Congestion control for VoIP. This document has not been revised, please do send data and comments (but please do say which specification was used for TFRC - i.e. was this RFC 3448 or 5348?) T. Phelan: We would also like to receive email from people doing testing/implementation. * QuickStart for DCCP (draft-ietf-dccp-qs-01.txt). There had been three sets of detailed comments on the draft, and a revised I-D had been produced. Authors would like next revision to be put to a WGLC. G.Fairhurst: Who has read the new version of the draft? Few people in the meeting had read this draft. Gorry would ask the list to see if we can some committed reviewers. * DCCP-NAT (draft-phelan-dccp-natencap-02.txt) G.Fairhurst: The chief aim of this work is accelerate DCCP deployment. Magnus W.: I think we have reached the stage where some UDP encapsulation approach is reasonable. I do not yet know where we do this in the IETF. G.Fairhurst: I agree, we should try to promote use of the native DCCP, but this seems like a logical thing to also do. Bryan F.: It is important that things get done, it is important to compare Tom and Remi's address and how addresses are handled. We should think about sharing the UDP port list. G. Fairhurst: My take is we need to get this done in a consistent way for TCP, UDP, DCCP, etc - and in fact for any transport that may yet follow. We need a consistent method. How do we discuss this? T. Phelan: We need to have a discussion in TSVWG, and look to see what is the best thing to do and where this may be chartered. G. Fairhurst: As WG Chair, I invite contributions to this topic, send comments to Tom's draft, or write a short draft of your own. Both would be most welcome. B. Ford: SCTP has seen 3 UDP encapsulation drafts, none of which have made it to RFC, and whether the fate of these SCTP drafts can be avoided. Michael Tuexen: The original SCTP spec ran over UDP. This was changed to run directly over UDP. There is much work in this area and we expect new running code in the near future. G.Fairhurst: I strongly suggest we do not us the "raw" format. DCCP is designed as a transport protocol it is naturally layered on IP. I would much rather see this called "native", if you need a name other than just saying this is the default DCCP. * Implementations There had been discussion on the list about the granuality of timers (see list), but there was no specific presentations. The Linux release has been updated. The PC user-space implementation DCCP-TP had also been updated, there were also other implementations in progress. The meeting closed. These notes were uploaded 26-11-08