DCCP meeting notes / Monday, March 23, 17:40 -------------------------------------------- Chair: Gorry Fairhurst Notetaker: Pasi Sarolahti 1. Agenda Bashing * Sally Floyd: I have not been to an IETF meeting for a while. I see there are not many people in the WG today, does this mean that DCCP is going to be dormant? * Gorry: Many of the documents on our charter are now complete. Now would be a good time to take new work. There are groups like the ledbat WG that are talking about perhaps using DCCP. We need new work, otherwise this activity could become dormant, please give this thought and if people have ideas, please do come and talk about it within the WG. 2. Document Status Gorry presented document status and reviewed the milestones. Overall progress has been good. 2.1 DCCP RTP The DCCP-RTP draft is in the RFC editor's queue (awaiting a REF to a document in another WG). The RTP port assignments for DCCP have been clarified with IANA, current assignments were shown. * Steve Casner: Do these ports have more value for DCCP than for RTP/UDP? * Gorry: The reason for doing this is that we have service codes as well, so either static or dynamic allocation can be used. * Remi Denis-Courmont: The port is used as a default value. My point was that, RTP recommends even/odd ports pairs. That cannot be obtained with the standard port 0 bind socket call, so an explicit default value is needed. Unfortunately, this might break the recommendation to use pseudo-random port numbers for security reasons. This is not an issue since these are the same in UDP anyway. 2.2 Service Codes * This document has completed WG last call, now waiting for the document write-up. 2.3 Simultaneous Open * This has completed WG last call, now waiting for document write-up. * Lars Eggert: The shepherding process is not working for these documents. Tom is busy and Gorry is the author. I suggest that we apply a bit of a different process for shepherding in this case. A write-up will be prepared and Lars will shepherd the document. 3. Active WG Drafts 3.1 Documents to be considered for WGLC 3.1.1 Quick-Start for DCCP (Gorry Fairhurst/A. Sathiaseelan) http://www.ietf.org/internet-drafts/draft-ietf-dccp-qs-02.txt * The protocol specification has been more or less stable since draft -00, the authors have been working on getting the details right. * Changes in draft -02 contain clarifications, harmonizing the behavior on different CCIDs, and now apply the same principles across different CCIDs. * The authors had updated the QS response behavior in the absence of feedback. * There was new clarification about using a common timer resource for both validation and nofeedback timers, instead of separate timers, based on implementor feedback. * People were asked to review the document, and comments were received from Vincent Roca and Sally Floyd. An email was sent to the mailing list to check these issues have now been addressed properly. This is a sign that the document is now quite mature. * Gorry (as Chair): Are there any comments about the draft from the audience? - No comments. * What should we do next? - This seems ready for WGLC, the milestone is now due. * Who has read the document? - Few hands. * Are there any implementation reports? - No. * Is this ready for a WGLC for the next version? - Few are supporting, no one against. * Who would volunteer reading the next revision during the WGLC? - Sally Floyd, Pasi Sarolahti. * Gorry encouraged others to also read and send comments. * The WG decided to proceed for WG last call in the next few weeks, after concluding the WGLC for CCID-4. 3.1.2 DCCP CCID4: TFRC with Small Packets (Sally Floyd, et al) http://www.ietf.org/internet-drafts/draft-ietf-ccid4-03.txt * This has been around for a while. * The changes are small, the authors had updated the TFRC references (the new version is based on RFC 5348 instead of the old RFC 3448). A section was added on the experimental status of this document, and some minor editing. * Sally reviewed the recent history of previous documents affecting this one, from the original TFRC specification (2003), CCID-3 (2006), the small-packet variant - RFC 4828, TFRC-bis - RFC 5438 that obsoletes original TFRC. (There was a timeline diagram in the proceedings). * CCID-4 has references to TFRC and the small packet variant. There are multiple references to the past documents that have been updated since. These should be OK, since this is intended to be just an experimental document. It has just been waiting for RFC 5348 to come out. Sally is not aware of any conflicts between these documents. She is not planning to go through the revising process to get the dependencies of TFRC and CCID-3 aligned, but this is clearly something that would be helpful for implementors. * Sally asked if this was ready for WG last call? There are no interesting technical issues here. * Lars: Is there a paragraph that explains the referencing dependencies? This would be useful to add if there is not. * Sally: I am pretty sure there is. * Gorry (as chair): This has been near WGLC for some time. I sent a note to the list asking for people to consider this for WGLC. There were no comments against, and some feedback from Arjuna on nits, but he thought this was ready. * Gorry: If no one is against publishing this, we will now go to WG last call. * Hum, vote did not have anyone for or against, but there has been support on the mailing list, so will start WGLC after this meeting. 3.2 Other WG documents 3.2.1 Faster restart for TFRC (Sally Floyd, et al)http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-06.txt * This I-D has expired. The authors are waiting for simulation results to analyse the issues. * TFRC-bis has held this back, requiring simulation work to be restarted. * There are some very recent simulations that the authors expect to become available on this (from Arjuna). Sally will look at the results and consider what the authors would like to do next. * She expects there will be a new revision. 4. Individual Submissions 4.2.1 DCCP/UDP (Tom Phelan) http://www.ietf.org/internet-drafts/draft-phelan-dccp-natencap-01.txt The author was not in the meeting, this agenda item was skipped. 6. Implementor Feedback * People continue to use DCCP, we know there are downloads of the most recent Linux implementation from the Aberdeen git server. * Remi Denis-Courmont: I have been using with DStreamer. I spotted a bug in the CCID-3 congestion control support, and this was fixed. 5. New Work * Gorry: Our charter allows us looking at new forms of congestion control. We should think what DCCP should be doing in the future. * Sally: I would be interested to know what all the non-TCP apps are doing for congestion control. What is happening in the real world? * Gorry: Part of this sounds like things being discussed in the ledbat WG. * Lars: Yes, this accounts for a lot of the non-TCP traffic. * Lars: Another thing I would like to see is congestion control for control traffic. The UDP guidelines talks about other applications that need congestion control. There are some applications where TFRC does not fit. It would be nice to support signaling protocols, such as bi-directional forwarding detection. This is an application demanding a certain probing rate. There are applications that have a high bandwidth mode and a low bandwidth mode. This is not necessary DCCP, but the expertise is here. * Sally: This sounds similar to multicast congestion control. * Magnus Westerlund: The only multicast congestion control work we have in RMT is around ALC. * Gorry: We could also think of much cruder congestion control that does not have huge demands for bandwidth, but needs to adapt in the face of congestion. DCCP could provide the framework, packet formats, etc. for defining such a congestion control. Ideas for new work would be welcome - please discuss on the list, or talk to the Chairs. Meeting concluded.