DCCP Meeting Minutes IETF 65 March 21, 2006 1. Agenda bash (see web site) There were no additions to agenda. 2. Review of work items All WG I-Ds that were pending publication are now in Auth48. draft-ietf-dccp-tfrc-voip has passed WGLC. - Tom is the PROTO shepherd, soon to go to IETF. draft-ietf-dccp-tfrc-faster-restart - This is a current working grouping item, authors are looking for implementation experience. Implementors please let the WG know. Lars Eggert will resign as a DCCP WG Chair after this meeting. Gorry Fairhurst has agreed to take over as a co-chair with Tom Phelan. 3. draft-ietf-dccp-tfrc-media (Tom Phelan) - We do not have enough implementation experience for this document, so the WG is putting this on hold until we get some. Colin Perkins (CSP) - We do not have anything over DCCP, but we do have experience with TFRC over UDP, so we expect this experience will transfer. I hope to have feedback using TFRC in the next few months. Eggert - Linux and KAME communities are implementing specs and may get to these. Tom - DCCP is in NS, see recent discussion on mailing list. 4. draft-ietf-dcp-user-guide (Tom Phelan) The last text was extracted to be tfrc-media. The authors are looking for input from people in the WG, and implementation experience. Eggert - During the WG last call, there was some experience and input that we would like to put in the user guide, particularly clarifications for the loss interval and packet loss rate. We have a student with some data, but it is not ready to show yet. a. Issue is packet size calculation (MSS or average?). It is not definite in this draft, but you do need to agree the values at both ends of the session. b. Estimation of loss interval. In TFRC, you are supposed to average over 8 samples. Some implementations mess this up, if they have less than 8 samples. Sally Floyd - We need to clarify these things in the TFRC spec. Phelan - I'm looking for an organizing principle for this. I will try to have a first draft with the new organization by next meeting. Eggert - Do we need to update the milestones for the user guide for "next meeting"? Phelan - There will be an update next meeting. I would like to see how the WG Charter discussion goes (next). 5. Rechartering Discussion 1) Core focus: - Maintenance of the core protocol of DCCP. - Modular extensions to DCCP. - Promote the use of DCCP by upper layers. 2) Maintenance of DCCP: - The WG will move drafts along the IETF Standards Track. - Make only tightly controlled, well justified changes. 3) Extending DCCP: - Identify extensions that would make DCCP attractive. - Be open to inputs and needs of other IETF WGs. - The WG will not do new congestion control schemes, but DCCP will support ICCRG by providing a deployment platform. 4) Promoting DCCP: - Specifications for other protocols over DCCP. Evangelism. Work in the second two areas will need the buy-in from this WG and may require AD approval before proceeding. A non-exclusive list of potential collaborating WGs are: TSVWG, AVT, MMUSIC, BEHAVE, ICCRG, TMRG. A set of new milestones have been proposed (see mailing list): The new charter will take the WG to Jun 2007 and include mobility extensions, RTP over DCCP, DTLS over DCCP. Allison Mankin (AD) - You would need to get a buy-in from the IESG/IAB to work on mobility in this WG. Eggert - This is the output of Vancouver discussion, where there were people in the room who wished to do this. Mankin - It would need to be socialized, discussions on the architectural placement of mobility are likely to follow. Ekr - I like the charter. Mobility seems appropriate. I would love to work on DTLS over DCCP, but I can not do it myself: So if people do not want to, that is fine too. Mankin - It would be good to work on DTLS. Floyd - I like the Charter. Eggert - Do we have consensus from this WG that they would like to work on these items and send comments, etc? That has been a problem lately, I would like to judge commitment. I would also encourage new authors to contribute. Ekr - We really need someone who knows DCCP better. Phelan - I am willing to work on it. Eggert - We will take the list of work areas to the DCCP mailing list. We can then adopt new drafts as appropriate. 6. Potential New WG Items: draft-perkins-dccp-rtp-01 (Colin Perkins) Slides available. This draft provides: 1. Framing mechanism for RTP over DCCP. 2. Extensions to SDP to negotiate RTP over DCCP. The draft does not define SIP for RTP over DCCP, this is a different issue. Framing: Instead of using multiple ports, just use just one DCCP flow and demux by payload type. Ekr - Why is this not done in UDP? Perkins - It could be. The convention for UDP is different, but you could do the same thing. Steve Casner - One motivator for separate ports is for reception of "only control" or "only data". This is good for multicast, which is not an issue with DCCP, since this is unicast. Perkins - There is also a SDP attribute to allow separate ports to be used (no multiplexing). Eggert - We do not yet have a NAT traversal story. Perkins - An open issue is how the RTCP interval is affected by the congestion control interaction. This needs further study. Comments are welcome. Mankin - The analysis is overdue. Perkins - It is a more general issue than a DCCP, and could be a separate draft. Phelan - The problem is that there may be a lot of sessions in DCCP, so the nominal bandwidth may be confused. One issue is asymmetric lines (e.g. ADSL). Perkins - This is a generic problem for RTP over any congestion controlled transport. Phelan - Should all profiles of RTP work OK with DCCP? Perkins - Yes, except, of course, the congestion controlled one. Signaling RTP over DCCP (using SDP): See slides. Perkins - Should we define standard DCCP Service Codes, or let each application define its own set? Phelan - Would this exclude other Service Codes being used by an application? Perkins - No, this defines sensible starting points. More thoughts from the WG are welcome. Eddie, Phelan, and others - OK. Perkins - Can we accept this as WG draft? Eggert - This depends on the Charter. Phelan - Do we need to coordinate with this in the AVT WG? Perkins - We need to pass it by for comment, but it does not seem to need a formal interaction. Eggert - Should we do a common last call? Perkins - This seems good. Craig White - Has the AVT WG seen or reviewed this document? Perkins - Not yet, but I am happy to let them. White - There is some stuff here that seems to have fallen by the wayside (e.g. separate control channel). Do you think it will be OK with AVT? Perkins - The multiplexing, at least, seems to go over well (some people are running out of ports in some large telephony applications). Whether people people also appreciate congestion control is a different story, but it may provide an incentive. . Eggert - We could roll congestion control for media into the TFRC media draft, if this is not specific to RTP. 7. draft-kohler-dccp-mobility-01 (Pasi Sarolahti) Slides available. This is a potential new WG items and is a follow-on from a much earlier discussion. Eggert - There are network protocols (e.g., HIP) that will provide mobility that is suited for all protocols. Do we also need to do mobility at the transport layer? It seems an open question. This needs to be discussed with the Internet Area ADs. Sarolahti - The approach is lightweight. Eggert - Yes but a transport-specific lightweight protocol means you need would need to redo this for each transport protocol. Sarolahti - HIP may not happen... Eggert - There are others: SHIM6, MULTI6, ... Sarolahti - SHIM6 is for site multi-homing. Sarolahti - An alternative is to tear down the connection. This does not compete with Mobile IP, Mobile IP may also be used. Perkings - Is SCTP's mobility now considered a mistake? Sarolahti - A nice use case is to have SIP on SCTP and then look at this on DCCP. Mankin - This is analogous to SCTP. We may hear about use cases later. There are a lot of things on the net that suffer adverse effects if you change a connection, e.g., NAT - see ICE, IPv4/v6 transition gateways, changes on the path may result in unreachability or thrashing. Sarolahti - It should work with NAT. Mankin - Why? Sarolahti - See rest of presentation. Kohler (via jabber) - This does work with NAT. Phelan - I am having experience with a telco who insists on SIP over SCTP, but they do not wish to use SCTP multihoming. Michael Tuexen - "Add-IP" in SCTP is not for mobility. It is for long-lived associations, e.g., a year, where you can reconfigure the hosts. This could be a different motivation. Sarolahti - This is a robustness feature (like multi-homing), rather than mobility. Kohler (via jabber) - I could change this to multiple addresses, rather than mobility. Sarolahti - Should this be Chartered in this WG? Magnus Westerland - Does this gain any advantage? Isn't it more important for DCCP to work on congestion control, deployment, etc? Do we have a customer that needs this feature (at this stage)? Sarolahti - There is skepticism about deployment for DCCP in a mobile scenario. This could be an incentive. Mankin - I am changing my position. The motivation was not presented right. This is your NAT traversal story. Your equivalent of ICE. This is more general. I would call it "GenCon". Westerlund - You have to be careful how you use multiple connections. Changing your path creates problems (these also exist with ICE). Perkins/Kohler - This may be useful, but I do not think it removes the need for ICE over DCCP, we need ICE over DCCP too. Phelan - This seems to me to be more than reliability to mobility (especially in the telephony world). Further discussion will be taken to the list. End of charter discussion. Eggert: Tom Phelan said he would work on the DTLS document (if there are no other takers), or along with another taker. Does anyone want to work on DTLS? There is still an opening for a new author, if one wants to join Tom. 8. draft-ietf-dccp-tfrc-voip-05 Slides available. The I-D has a name change to "TFRC for small packets" (rather than VoIP) and has completed WGLC. A companion draft will later specify a CCID (4?) to define the mapping to DCCP. Westerlund - The byte drop mode pushes TCP towards smaller packets, to obtain high performance at high packet loss. Floyd - It only favors small packets for TCP when the packet drop rate increases to above 15%. It is not dangerous in the Internet. This is good for TCP, because it makes it less likely to drop SYNs, ACKs, etc. The incentive is still to use large packets for TCP. It is also good for VoIP. Westerlund - The place it starts to get really unfair is at substantial loss rates. Floyd - TFRC is fair to itself, but at high loss rates, it just means that things are not totally fair (in favor of the TFRC-SP traffic). Floyd - I have made some small changes have been made to ns2, to allow larger initial windows (not in the TFRC spec). CCID-3 says this is allowed. There are some extra things to do when you do this. I intend to write an I-D on this. There are three errata to TFRC. Perkings - Should this be an Errata for TFRC? Should we actually produce a new rev of the TFRC specification? Floyd - A little more work would be needed, but this is the better thing to do. White - Thank you for your explanations. You said we do not know what Internet drops really are. In the core, congestion is not normal, so you would not expect to see high drop rates, except for link cuts. What does the response curve look like under recovery? Floyd - You mean a transient event? If you are going to tell people to deploy it only in certain scenarios, then how does the user know? This is end-to-end congestion control. White - This is a last mile issue (with possible congestion), rather than in the core. What behavior would we see under that scenario? The queue depth and consideration of traffic engineering in the core. Floyd - I will think about that. Floyd - The faster restart draft is now available (currently expired). This allows faster start after an idle period, because you know some path history, and be more aggressive. Restart is up to 8 small packets (4 KB). It needs someone to do some experiments and/or simulations, and look at worst case scenarios. We are looking for inputs. Eddie and I will eventually work on that... 9. Eggert (WG Chair) We have dropped the ball on "TFRC maintenance", it should have been on the Charter. It will be on the Charter when we send it for review by the list. 10. Mankin (AD) The IANA wants an expert reviewer for checking DCCP port requests against the specification. Any volunteers? Eddie - I assumes it is me (for a while). Mankin - They expect fast turnaround. A day or so. There could be a back-up person too. 11. Floyd Thanks to Allison for getting us through Auth48, etc. Meeting closed. The next DCCP WG meeting is at IETF-66.