DCCP Working Group, November 6, 2006. WG Chairs: Gorry Fairhurst & Tom Phelan Note-taker: Sally Floyd. 1. The agenda was reviewed. 2. Gorry Fairhurst (GF): Report on Document status. 3. Sally Floyd (SF): TFRC-SP, draft-ietf-dccp-tfrc-voip-06.txt. This draft has finished its second WGLC. Sally will make the changes that came up on the mailing list, and submit the revised draft by next week. After the discussion of this draft, the issue came up of TFRC-SP over paths that only allow for *very* small segments, e.g., 50 bytes or so. Colin will send email to the list, and Sally will add something to this document about TFRC-SP not being suitable over these paths. This is discussed briefly later in these notes. GF: The new draft will be forwarded to the IESG with a note recommending publication as an Experimental RFC 4. Sally: RFC3448bis, draft-ietf-dccp-rfc3448bis-00.txt. GF: When will this be stable? SF: I expect this to be mature by the next IETF. GF: I'd like people to look a this. Colin Perkins (CP) : What is the status of implementations? Are people progressing with this, e.g. for DCCP? If we are likely to get experience, should we wait for this before publishing? SF: The only ones I know of would be in CCID3 Question: There was a question from jabber about W_init and segment sizes that will be answered by email. Ian McDonald (IMD) - Via Jabber : CCID3 is being implemented for Linux, but is not audited against the RFC... Arjuna Sathiaseelan - Via Jabber (AS): The calculation of X_inst = W_init/R needs to be checked. I had suggested using packet size "s" instead of MSS to calculate W_init. SF wasn't able to respond, but would dfo via the list. 5. Tom Phelan (TP): DTLS over DCCP (no viewgraphs). Current draft is draft-phelan-dccp-dtls-01.txt, which is stable. One question that came up last time: What Service Code should be used? - The current proposal is to use a different SC for each DTLS service (as in application over DTLS), this follows the way HTTPS is viewed as separate to HTTP, etc. This is an issue that needs to be thought through. The draft seems be mature apart from this. Gorry: We can take the service code discussion with the discussion of services code under the User Guide item. Gorry: Who has read this draft? Two people in the room. The author thinks this is ready to be made a WG item, and the Chairs will ask for adoption by the WG on the mailing list. 6. Arjuna Sathiaseelan: Faster Restart (FR) The authors had not submitted a presentation (the FR I-D had not changed since the last IETF meeting). This talk was seeking to determine what work was needed to progress. What are the simulations that we need to do? * Which receiver algorithm should be used, when? * How do you evaluate? - Could use R-Scores? * What do you take as the minimum rate? 4/RTT? 8/RTT? Arjuna is happy to work on thsi and offere text, and would like to co-author. SF: There are several questions that need to be answered: * What are the dangers of congestion collapse, if any, or of periods of high loss, if many flows do this? * Is this good for the flow itself? * What if packets are dropped? * Fairness with TCP? SF: The reason we chose 8, is that you know that 4 packets was OK (startingh from scrath - the initial window for TCP justifies this), you now know more about the path than someone just starting, so 8 packets should be safe? SF: We need to look for bad cases that may arise when people are just that little more agressive. This is not just TCP fairness, we need to know about fairness with other users (e.g. of TFRC, TFRC-SP). GF: So this is one of things we need to determine? SF: Yes. TP: I think this is also about being fair to flows that go slient, which is good behaviour. We need to see what happens when a slience period is filled with traffic (e.g. by sharing TCP flows): the notion of a fair-share. GF: OK, and this could be very acute when we have toplogies with some flows having very short path RTTs. AS (via CP): The problem happens when the traffic is very bursty, e.g. sending one packet every path few RTT - so in this case, can we still maintain 8 packets/RTT as an allowed rate? SF: FR says you can send 8 RTT if you were sending this before the idle period, and there was no congestion. Magnus Westerlund (MW): This depends on what is an idle period, in this case the source was sending at less than 8 packets per path RTT. SF: I don't recall what the I-D says. SC: When looking a sharing, UDP applications can ignore also ignore CC, gaming is not then an issue. SF: Can an application trick CC, by choosing one packet size/rate and then change this to get benefit? 7. Colin Perkins (CP): RTP and DCCP There has been some feedback on details (discussed on list). There are no known open issues, please read and send comments to the list. I think we should now take this to WGLC soon. SF: I read it and it seems OK. GF: Whho has read it? Who thinks it is ready for WGLC? (Some have read, none object). GF: Will Colin present this in the AVT WG tomorrow? CP: Yes, and also the related draft on RTP multiplexing. 8. Sally Floyd (SF): CCID4, TFRC-SP for DCCP. Current I-D is draft-floyd-dccp-ccid4-00.txt. The next step would be to make this a working group document. We would like this to be considered for publication as an Experimental RFC. Gorry: This specification can not be finalized until TFRC-SP is reviewed by the IESG and we have feedback. I think the best approach is to get these reviews before progressing this in the WG. Sally: OK, we won't take this further in the group until the IESG review comments are received. GF: Maybe we can get implementation experience before this becomes RFC even? SF: Well... Lars Eggert: This isn't currently a WG item... GF: We need to get feedback on TFRC, and people to read this before making it a WG items. How many have read this? (1 person in the room) Lars Eggert (LE): Since TFRC-SP is suggested as Experimental, then this would also be Experimental. GF, SF: Agree. TP: We will need to get a postive feedback from the list from people who have read this. CP: Concerning SP varients, there was discussion on the list on small path MTUs and (un)fairness. SF: Yes, this needs to be added to TFRC I-D. CP: This type of issue has also arisen on the AVT WG list, when peopel mean a MSS of 36B. SF: That's a problem. Factors of 2-3 do not seem to be a problem, more unfairness is bad. GF: Serial links, the sort of links that 6lowpan is dealing with, etc... are small. SF: Could forec PMTUD in TFRC, or know you can't use over these paths, but the sender does not know these paths exist... SF: You could write a warning that bad things will happen. CP: I don't have an answer, except to do this. GF: What is fair, what would TCP do? SF: We are trying to prevent congestion collapse. CP: They may be unusuable for TCP? SC: They may be so contrained that they can only do this one voice link. SF: I'm happy to put language to say there is a problem with these links. GF: OK so there are various "odd" cases: - Very small MTUs - 536B IPv4 MTUs - Jumbo frames (which probably are high speed) We should make sure these are captured correctly in the TFRC-SP I-D before forwarding to the IESG. 9. Sally Floyd (SF): CCID2, new ideas (no viewgraphs): Is there an interest in a slowly-responding variant of CCID 2, that is, AIMD with different increase and decrease parameters? This would be intended to go to Proposed Standard. CP: Who would use this? SF: Applications that wanted to be more slowly-responding than CCID 2, in terms of not halving the sending rate in response to a packet drop, but that preferred CCID 2 to CCID 3. SF: a small-packet variant of CCID 2 (no viewgraphs): Is there an interest in a small-packet variant of CCID 2, in the same sense that TFRC-SP is a small-packet variant of TFRC, with a 10 ms interval between packets, window increases like those of a flow with 1460-byte segments, and accounting for bandwidth used by packet headers? If done, this would be intended for Experimental, with all of the caveats of TFRC-SP. 10. Richard Nelson: Implementation Report for Linux. Ian McDonald is fixing bugs in Linux, and working on the API, etc. LE: We had a hard time figuring out which of the implementations are standards comformant. At the time we did this, the implementations did not seem to be based on reading the RFC, but seem to be based on the Lulea implementation. We will need something more clear to define what goes on to progress TFRC, etc along the standards track. SF: Why do you not understand conformance? LE: Not all implementations follow the same understanding of loss-intervals. Some of these do not follow the actual Spec - more evolve the code. RN: There has been some testing between the Linux and FreeBSD implementations. Feedback bugs have been found and fixed, the latest Linux kernels do not have all the fixes, there is a backlog of fixes. GF: Things have been improving, but Lars is right, we need implementations based on the RFC, and may need to think about how to do implementation conformance testing. At the next meeting we would be happy to have more implementation reports, with slides. 11. Drafts needing work - TP: TFRC Media Guide. This document is trying to discuss using DCCP from an application point of view, original inputs came from various people, but has not progressed recently, we need input from implementotrs, among others. GF: Are we ready to move forward on this? TP: Yes, I will revise this document. 12. Drafts needing work - GF: DCCP User Guide. Do not read the current user guide I-D! This document should be designed to give Guidance to users and implementors, not to address issues related to CCIDs (these go in the media-guide). Things that are needed: firewalls, feature negotiation, service codes, APIs. Do we have any offers of new authors, or contributors? - please do contact the Chairs if you are interested. The implementors would be a nice source to contribute what they are able based on their experience. 13. GF: Discussion of service codes The WG needs to look more carefully at Service Codes: The purpose of service codes is to identify applications to clients. Joe Touch has an internet-draft on port names, a proposed similar method for TCP (but different). Who SHOULD vs. MUST use different service codes. Do DTLS, RTP, etc., get one or many service codes? The DTLS work might stall until we understand how to use service codes. CP: One reason we may not be seeing service codes in implementations might be that applications do not want to be identified to middleboxes. GF: Does SC:0 actually mean this? CP: No, but people may think it does. GF: Another problem is a lack of current SC values. Allocation does not require an RFC. TP: What identifies the flow, SC, or ports? Is there a wildcard service code/port. GF: What about SC:0? TP: What does this mean. SF: The SC concept was developed by Mark Handley, I'm not sure the authors have a strong preference. GF: Yes, now we are implementing, we need to progress. TP: DTLS suggests several servcie codes. CP: RTP can change the "code" as the flow proceeds, do a DTLS on teh same port and see if it works. TP: OK, then the DTLS "Open" fails, then RTP just carries on, ignoring this. CP: Yes, mainly to get around a SIP issue. May be we want to allow something similar, when RTP is used over DCCP (RTP is an important application). TP: So, "MUST" use differents SC's is wrong, it would be better to say "SHOULD". CP: It's input to the debate. GF: I think you are motivating that the SC should be RTP, and RTP/DTLS uses the same code. CP: That's were things are going, but I am not sure it is the best way. TP: I proposed you "SHOULD" use a different SC, but "MAY" use the same one... That was downed then. Things may have changed since then? MW: I do think clean explicit multiplexing are desirable, and there are cases where this is necessary. We should encourage explicit SCs. CP: I agree with Magnus, we need though to deal with the current evolution of RTP - or wait for other WGs to do this. There are varients of secure, zRTP, etc. We don't want one for each. GF: Yes we don't want vast numbers of combinations... TP: We need to discuss this on the list. GF: This is stalling the work on DTLS, we need to discuss service codes on the list. The meeting closed.