Here are the notes from Monday's meeting - many thanks to Pasi for acting as scribe. This draft copy will be uploaded to the proceedings. As usual, please review the notes and send any comments to me. Best wishes, Gorry (as DCCP co-chair) DCCP meeting notes / Monday, March 23, 17:40 -------------------------------------------- Chair: Gorry Fairhurst Notetaker: Pasi Sarolahti 1. Agenda Bashing * Sally Floyd: I haven not been to IETF for a while. I see that there are not many people in the WG, 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 ledbat that are talking about perhaps using DCCP. We need new work, otherwise we should make the activity dormant, please give it a thought and if you have ideas, come talk about it. 2. Document Status Gorry presented document status -- overall it is good: * DCCP service codes, simultaneous open are waiting for write-up * DCCP-RTP is in RFC editor's queue (awaiting a REF) 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 we can have either static or dynamic allocation. * Rémi Denis-Courmont: It 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. Milestone update -- quick look at how the WG is doing with the milestones. Service codes update * This completed WG last call, now waiting for the document write-up. Simultaneous open update * This completed WG last call, waiting for document write-up. * Lars Eggert: The shepherding process is not working for these documents. Tom is busy and Gorry is the author. Suggest that we apply a bit of a different process for shepherding in this case. A writeup will be prepared and Lars will shepherd the document. 3. Active WG Drafts 3.1 Documents to be considered for WGLC: Quick-Start for DCCP (Gorry Fairhurst/A. Sathiaseelan) http://www.ietf.org/internet-drafts/draft-ietf-dccp-qs-02.txt * The protocol spcification is more or less stable since draft -00, the authors have been working on getting the details right. * Changes in ver. -02 contains clarifications, harmonizing behavior on different CCIDs, combine together and apply same principles for different CCIDs. * Updated the QS response behavior in the absence of feedback. * Clarification about using common timer resource for validation and nofeedback timers, instead of separate timers, based on implementor feedback. * Corrected nits. * 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. I think 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 next? * Algorithms are stable * Seems ready for WGLC, milestone is now due * Who has read the document? Few hands. * 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 in WGLC? * Sally Floyd, Pasi Sarolahti. * Gorry encouraged others to read and send comments. * The WG decided to go for WG last call in the next few weeks. 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. * Changes are small, updated TFRC references (new version RFC 5348 instead of the old RFC 3448), added section on 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), small-packet variant, TFRC-bis that obsoletes original TFRC. (There was a timeline diagram in the proceedings). * CCID-4 has references to TFRC and 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 Faster restart for TFRC (Sally Floyd, et al) - The I-D has expired. http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-06.txt * This is waiting for another revision, with some simulations to analyse the issues. * TFRC-bis has held this back, requiring simulation work to be restarted. * There are some very recent simulations that we 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 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. * Rémi Denis-Courmont: I have been using with DStream. I spotted a bug in the CCID-3 congestion control support, and this was fixed. 5. New Proposed 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 apps 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. Meeting concluded.
