DCCP Working Group Meeting, July 23, 2007. Notes from Sally Floyd and Tom Phelan. Agenda Bashing Document Status - Gorry. * To-Do Milestones. [See presentation.] "We are looking for someone to contribute to a user guide." Lars wants someone to write a document on middlebox considerations for DCCP, in the BEHAVE working group. This would be about how NATs should munge DCCP packets that traverse them, mirroring other BEHAVE documents about UDP or SCTP. The DCCP-specific issue will be about service codes. TFRCbis - Sally Floyd Version 2 of draft TFRCbis has larger initial sending rates that TFRC, reflecting changes in TCP. Three main changes from -01: * Mechanism for resonding to the feedback packet after an idle period. * Response to idle and data-limited periods. * Use of unused send credits. [and so on from presentation.] Mark Handley: For the last bullet on the last slide about related work, what will the app writer do about data limited periods, given what is suggested in the last bullet for TFRCbis? Should the app pad the flow so that it will get what it needs when it needs it? That's what I expect they'll do. We should think about people's incentive to pad their sending rate during idle periods. Sally: By the same argument, apps would pad TCP data too. Mark: The TCP ramp up is faster, so there is less incentive for padding. If you're using TCP, you're not real time, so a fast ramp up less important. Colin Perkins: It's been suggested many times. Randall Stewart: If you're not being a good citizen, why use DCCP in the first place? Why not just use UDP? Gorry: Is the current version of TFRCbis stable. Sally: There are two changes to make, listed in the slides, and then it should be stable. Gorry: We asked for simulation work to support, and now we have it. Feedback to the list is now needed. TFRC/RTP, Colin Perkins presenting for Ladan. * Overview. * Changes since -07 [See presentation.] Question: How do you decide how many feedbacks to send? Answer: If you know the expected data rate, then it is not a problem. Magnus: Relationship between RTP sending rate and RTCP sending rate? Gorry: Are there any complications about using 3448bis instead of 3448? Colin: There might be some changes in the information to be provided, but other than that, he doesn't think there are any issues. Faster Restart - Sally Floyd [See presentation.] The draft is reasonable stable except that simulations are needed on worst-case congested scenarios. Colin: For the ping during idle times, what happens when the RTT is much smaller than the frame rate of codecs? Sally: We're either going to remove the ping altogether or make it optional. Our inclination is to take it out. Colin: If we leave it in, we need to specify interval better. Colin: The draft says that the API must not report received zero-length packets. This seems to create a strange non-symmetric situation. Gorry: More about application-level keep-alives. Tom Phelan: I thought we agreed last time that apps could send and receive zero-length data packets? If CCID needed to send keep-alives, it would need to create something else. Mark Allman: Could I use Faster Restart in TCP? Sally: Not until the simulations are done exploring worst-case scenarios, but then if it works someone could propose this for other transports. Mark: Part of the worst-case simulations could be in the context of TCP? Sally: The worst-case simulations would be of a congested link with everyone using Faster Restart. Lars: Maybe your path is about to change? Sally: The allowed sending rate takes the last feedback packet into account. If you have loss then it went down. Should we add something that says that loss in the last feedback packet effects what you can do when you restart? Lars: Maybe. Lachlan Andrew: Should the increase after the idle period be linear instead of exponential with a higher starting point? Sally: I wouldn't want to go faster than quadrupling the sending rate. Lachlan Andrew: Should the quadrupling slow down as you approach the old rate? Sally: That's possible, but it might not be worth the added complexity. Service Codes - Gorry Fairhurst * DCCP Service Codes * Changes in rev -00 * Service code and ports [See presentation.] Mark Handley: Multiple service codes on the same port? Mark does over the past history of service codes, explaining why there is now the ambiguity between ports and service codes. The motivation is that any application that wants one should be able to have a service code. There is a shortage of ports, so we need to be able to allow multiple service codes for a single port. Question: A DCCP Reset is sent in response to a bad port number. Lars: People have started to use DNS serve records, where there isn't a well-known port. There is a greater push behind this that for DCCP service codes. Do maybe we should assume DCCP service codes have failed, and give them up. Mark Handley: These are two mechanisms for two different problems. Lars: Talking about the problems introduced by DCCP service codes. Modifying socket handling? Mark Handley: The main different is how you handle connection set-up. That is protocol-specific in any case. The intent of service codes was never to be cryptographically secure, or to prevent applications from hiding. Lars: Middleboxes won't believe the service code data, for the same reason that they don't believe well-known ports. Mark: It depends on what kind of middleboxes you are talking about. The service code is not addressing security. * Implementation Mark: Trying to have a wild-card service code is against our intention for service codes. Colin: Do applications listen on ports, or on service codes? Gorry: I will go throught the three levels on the slide again. (1) Minimal support, use wild-card service code. (2) Standard support. (3) Enhanced support: Mapping SC to ports. For (2), Mark says that a single port can have multiple service codes. Mark proposes (2b). There can be multiple service codes for a well-known port. Colin: A socket API question. Lars: "Everyone now knows why we need this draft." Gorry: Should we allow a service code of zero as a default service code? Colin: In practical terms, ... Mark: I am not saying that this is an inherently evil thing to do. We can allow it. But we don't recommend it. Chair: "The draft doesn't cure the confusion about service codes yet." Lars: It would be very nice to come up with a scheme that doesn't require requests to IANA (e.g., for registering service codes). Mark: "It should be possible to do a dual registration." DTLS over DCCP - Tom Phelan [See presentation.] TFRC Media Guide - Tom Phelan [See presentation.] This needs some new people to read it. Implementor's Status - Gorry: Linux: The DCCP implementation is being taken out of the main tree for Linux for the moment. It will be merged back when the Linux API is more stable. Quick-Start for DCCP - Gorry: * New in Revision -01 * CCID-2 * CCID-3 * Problem Statement: QS Interval * QS Interval * What Next? [See presentation.] Is this ready to become a WG draft? Mark Allman: The minimum interval is a second? Shouldn't it be longer? Gorry: What about ten seconds? Mark Allman: That is better. It might merit some investigation of what that number should be. Take the question to the list of whether this should become a WG draft. Lars: Should this be in tsvwg instead? CCID3 Dropped Packets option - Sally: CCID4 (for Small Packet TFRC) - Sally: [See presentation.] Gorry: Ask list for feedback on whether these should be WG drafts. This can proceed quickly if it is adopted (there no need to wait until next meeting for WG Last Call).
Updates and corrections are welcome. - Sally http://www.icir.org/floyd/
