Dear WG, Here is the first take at the minutes, thank you to the minute takers, and Jabber scribe. Please send any comments, or updates to the WG Chairs, and we'll fix them. We like to express our thanks to Pasi & Eddie for agreeing to postpone their talk to the next IETF meeting (when we ran short of time) - They have an updated individual draft (and their slides are included in the proceedings). Best wishes, Gorry & Tom ----- Datagram Congestion Control Protocol (DCCP) WG WG Chairs: Thomas Phelan <tphelan@xxxxxxxxxxxx> Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> Note-takers: Haitham Cruickshank & Sally Floyd 1. Agenda Bashing 2. Document Status Tom Phelan introduced the work items and status. The Small-Packet (SP) Variant of TFRV was with the WG Chairs, who needed to prepare a write-up for the IESG. This was followed by a review of the new Charter by Gorry Fairhurst that highlighted changes since the presentation at the last IETF. Gorry: Are there any comments on the Charter? Sally Floyd said charter was good. Tom Phelan noted that an Errata had been filed for the DCCP spec. This had not received negative comments when posted to the DCCP list. It had just been sent to the RFC Editor and implementers should note this when reading the DCCP Spec. 3. Active Drafts 3a Faster Restart Sally Floyd presented an update on <draft-ietf-dccp-tfrc-faster-restart> on behalf of Eddie Kohler (who was present via Jabber). Describing an enhancement to TFRC (also CCID3) after an Idle period. This is slightly more aggressive than TCP would currently be. Arjuna and Vlad had made comments to the list about various issues such as the impact of the idle period during slow-start and issues of sending lower packet rates at the start of an idle period. Text relating to both of these had been added to the latest rev of the draft. The reported receive rate now also notes the number of packets that were received. There are some options, and there are issues still to be addressed. Eddie: Clarified that the reporting in an idle period was actually not one packet per RTT, but actually one packet per idle period, which is worse. Tom: What do the words "draft draft draft" mean in the draft? Sally: These were added by Eddie, these bits are work in progress. Further inputs are being looked for. 3a1 Issues with faster-restart. Gorry presented some simulation results of TFRC and Faster Restart on behalf of Arjuna Sathiaseelan (who was present via Jabber). There were some issues with the 2.30 release of ns2; he had worked on a fix (Sally also has a new fix). These now need to be compared. Some simulations are needed. Sally does not want to do this, Eddie may? After that the draft will need to be updated. Tom: There is a milestone for Dec 2006 for Faster Restart, is this reasonable? Gorry: Arjuna has volunteered. Sally & Gorry: This seems reasonable, unless we find something unexpected in the simulation results. 3b User Guide Tom Phelan presented an update on the User Guide, <draft-ietf-dccp-user-guide>, and media guide <draft-ietf-dccp-tfrc-media>. The user guide needs a re-write and we need to work on this, primarily on implementation experience. TFRC media is also awaiting practical experience. Gorry: The TFRC media Guide is first on our list of chartred items, giving experience with UDP, TFRC. Tom: Yes. Gorry: What do we need in the User Guide? Tom: We need inputs, based on the API needs, etc. Gorry: I would also like to see input on NAT traversal and DCCP Service Codes; how to actually use DCCP. Tom: We need both inputs from the implementers and this WG. Should we trawl the list to look for content? Collin Perkins: Yes, we need a mixture of implementor inputs and how the WG sess the advanced features being used. I expect this to iterate. We can not write this today. Tom: OK. Gorry: That sounds like the right way to go. Tom: I can do a new rev by the next meeting. Gorry: This is also something we need feedback from the group to get the correct section names set out. Tom: We also need people to look at the streaming models in the media guide. 3c Implementation feedback & issues 3c1 Linux DCCP Implementor Feedback from Ian McDonald. Gorry Fairhurst presented on behalf of Ian McDonald (participating via Jabber). Ian had been working on DCCP on Linux 2.1.68rc1. There is incremental improvement, but no TFRC-SP support yet. Testing had been done with netem, and some live tests. Still much work needed to meet the spec, and there are known issues on performance. There is still a problem with high-speed links. Tom: Where did the limit come from? It says on the slide, high-speed low latency, what were the conditions? Ian: The link is 100 Mbps. It breaks when there is a router in the path. Eddie: What does "breaks" mean? Ian: It re-synchs. Tom: Could we send a description to the list? Ian: This a performance problem, not a protocol problem. Gorry: We should encourage such implementation, and the Chairs and WG would like to know what is happening and help were they can. 3c2 Linux DCCP Implementor Feedback from Andrea Bittau This was presented by Mark Handley. CCID2 and CCID3 have been implemented. There are implementation issues (only long sequence numbers are supported). ECN is supported but not yet linked to IP. Feature negotiation works, but the API needs to be hooked up. For CCID2, the timer measurements are in clock-ticks, with resultant problems for low delay links (which would give a zero time). ACK Ratios not yet supported. Aaron: Is there a reason for the timer resolution to be in Hz? Mark: Not sure, need to ask Andrea. The protocol uses a socket type of SOCK_DCCP, which may not be the right thing to do, and probably should be more general. SOCK_Stream is probably not also right. What should it be changed to? Colin: What is SOCK_Stream defined as? Mark: The manual says this is a byte-stream. Aaron: There are other options for the name of the socket: SOCK_unreliable_stream; SOCK_Congestion_controlled, etc. Eddie: The service code was extensively discussed on the Linux list. Ian: My implementation has a socket buffer, with a memory limit, but this is not merged yet. Eddie: Some people wanted the service code to be optional, and he argued against. A discussion followed on the size of the socket buffer queue. There was agreement that a large queue is not needed, but a queue of at least one packet is probably a good idea. The API to the service code also needs to be clarified. It currently has no buffer for input to DCCP. Colin: My feeling is that there should not be a big buffer here. Mark: Right, but I think it should have a queue of at least one, you do not want to have to go to user-land each time an ACK arrives. You probably should configure this. Colin: Our experience with interactive video is that we would like it to be small. Mark: Yes, but there are issues in waking up the application too often. We need some sensible approach to get good performance. Aaron: Are there two implementations, or one? Mark: These are the same implementation in Linux. Feature negotiation works, but the way to get the result of the negotiation is not yet available. There are lots of patches expected to come through in .19 release. He expects a full stable release mid of next year. 3c3 Implementor Feedback of TFRC from Colin Perkins Colin Perkins presented on experiences with interactive video using TFRC. He described joint work with ISI funded by NSF. His experience was of using TFRC in user space, and some open issues that may impact implementation of DCCP CC methods. This follows the TFRC profile in AVT. This is approx 8 Mbps of video, and packet spacing is hard in user-space, which is an implementation issue. The end result is that stability is hard with RTTs of less than 10 or 20 ms. It gets more stable at larger RTTs. Mark: I have a student is working on a window based TFRC, but the work is not yet ready to show, but it does work quite well. Jabber: More accurate timing might help. Would it work better for low latency links if you used a smaller timer tick? Old kernels used 10ms, newer can use 1 or 4 ms. Colin: It certainly helps in MacOS which gets more accurate timing and is more stable. Jabber: You can set the timer ticks to whatever you want with the new kernel. Colin: OK. This also impacts feedback timing, which can be an issue. Mark: This implementation is in user space. How many of these problems go away with a kernel-based implementation? Colin: Depends on timing, its still involves application activity. Mark: It must be easier than waking the application up for everything. Matt Mathis: Did you look at the sensitivity to other things happening on the system? Colin: Systems were more or less idle. Matt: There can still be a lot of background chatter. Jabber: We believe these problems will go away if we have a kernel implementation. Colin: Agreed. Jabber: Others have tried timers in microseconds, and let you track the RTT is microseconds. It works fine there. Eddie: What is an acceptable buffer size here? Colin: One video frame. Continues presentation saying adaptation is easier at a higher frame rate. A better codec would help, and we need to understand the quality that we get. Kernel DCCP would help. Not sure if we understand this problem good enough to get issues sorted for the media guide. Gorry: How long until we have the information for the media guide to be updated? Colin: Some initial advice could be available in about 1 year. There are a lot of open issues. These are mainly are codec issues and do not relate to DCCP. Gorry: We need to understand what we can do, and write this based on what we have. Colin: Yes, and accept that the media guide may need to be updated from time to time. Eddie: Some of the problems might become easier with a kernel implementation. I do not think that the media guide should be based on user-level implementations, when it is not clear which issues come from this and which do not. Colin: Sure, but it is the best we have got. ?: The experience may also vary depending on which level the implementation is at. Colin: We do need to do the same sort of experiments in the kernel. Mark: We have talked off and on about using the TFRC rate as a reference rate (rather than a strict limit), and allowing the CCID3 sender to go above and below that rate. What is your view? Colin: It may. Mark: You could allow +/- 20% of the reference rate, keeping the application in control. The CC would only impact when it changes beyond these bounds. This helps change the time-scales. There are lots of unanswered questions here. Tom: Most of these are interactive issues. The media guide (currently) deals more with streaming media, rather than with interactive media. Do you have streaming experience? Colin: Not really in these tests. Tom: Can we write-up streaming and just say interactive is crazy in the media guide? Gorry: No, but we could continue the split the advice into conversational and streaming and give different advice in each. 4. Potential New WG Items 4a DCCP CCID4: TFRC with Small Packets Sally Floyd presented on < draft-floyd-ccid4-00>. There was one correction to a slide, concerning a label that should have been "max sending rate" (not min sending rate). The I-D is an individual I-D, but intended for WG adoption. ?: Does CCID4 mean there is a maximum sending rate? Sally: Yes, 100 pps. Mark: Does TFRC-SP have oscillations around the boundary of switching the method for reporting loss event rates at the two-RTT boundary? Can a discontinuity occur, where the sender jumps in rate to a higher threshold because of the loss interval? Sally: We looked, a little bit. Mark: If there were losses in bursts of 10 packets, then if these fell in a bad interval there could be really severe oscillation. Sally: I will go back to TFRC-SP and check this. I think 2 loss intervals should be OK. Gorry noted we need some people to read this new draft. 4b DTLS over DCCP Tom Phelan presented on <draft-phelan-dccp-dtls-00>, about transport layer encryption. DTLS could potentially use the DCCP handshake to carry the DTLS setup. He described clarifications for PMTUD in DTLS will be constrained by DCCP PMTUD method. Gorry said the draft should say which service code should be used. He also spoke about what would be the impact of changes to DTLS. Eric Rescorla: A new version of DTLS should automatically negotiate, so changes in version should not be a problem. Tom: I will add text on this to say DTLS/DCCP will track updates to DTLS. Mark: This question of service codes is a good question. I guess I view DTLS as a content transfer encoding rather than a content type, and service codes describe content type. At first I thought it should stay the same as the port and that it should be the same even if the content is encrypted. We need to decide. Gorry: I agree, this is a crucial point for deciding. Firewalls may have a view on the content being carried by DTLS rather than the content. Mark: There is no obvious right answer. We need to decide. Tom: We should take this question to the list. If we set the code to say a flow is video, this may be more useful than saying it is unknown encrypted content. Collin: My thought was the service code reflected the server, but I can see the other argument too. I do not like the current proposal though. We need to decide. Eric: What people do in TCP is a separate port for each application running over TLS, or you use the same port and have a de-multiplexing. Again, the WG is looking for some more comment from the list, and then we can see about making this a WG item against our milestone. 4c TFRCbis (update to RFC3448) Sally Floyd presented on <draft-floyd-rfc3448bis-00>. This is a maintenance update that was requested at the last IETF, to encompass the Errata, larger initial window, etc. The WG was asked if they wished this to proceed as a WG item. A hum confirmed there was support for adopting this as a WG item. There was no hum against. The next rev of the I-D will therefore be accepted by the Chairs as a WG draft. Gorry noted we still do need some people to read this new draft. 4d RTP over DCCP Colin Perkins presented on <draft-perkins-dccp-rtp-02>. He spoke about nominal bandwidth, RTCP feedback, and the implications of DCCP capacity changes. There was still more work to do. Mark: Suppose you have a case where your codec can adapt rate by an order of magnitude. What do you choose as the nominal bandwidth? Colin: To be safe, you have to use the bottom range of bandwidth. Trying to make the RTCP reactive is going to be far too complicates. You could also renegotiate. We should not duplicate things in the user and media guide. There are some more issues to be included in the next draft. A December milestone should be OK. Gorry: This has been tabled at two IETFs now, and is in response to a charter milestone. Who read either of these two versions? - Some. A hum confirmed there was support for adopting this as a WG item. There was no hum against. The next rev of the I-D will be accepted by the Chairs as a WG draft. 4e DCCP Mobility The authors had updated the I-D <draft-kohler-dccp-mobility>. This is an individual draft (see notes on Charter revision). It was agreed to postpone this discussion to the next IETF, where there would be more time. ---
