The minutes are attached, this time in a file with a *.txt name... - Sally http://www.icir.org/floyd/
DCCP Working Group, November 6, 2006. Note-taker: Sally Floyd. Agenda review. Gorry: Report on Document status. Sally: TFRC-SP, draft-ietf-dccp-tfrc-voip-06.txt. This draft 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. Sally: RFC3448bis, draft-ietf-dccp-rfc3448bis-00.txt. Sally expects this to be mature by the next IETF. Question: What is the status of implementations? Question: There was a question from jabber about W_init and segment sizes that will be answered by email. Tom: DTLS over DCCP (no viewgraphs). One question that came up last time: What service code should be used? Gorry: We can take the service code discussion with the user guide. Who has read this draft? Two people in the room. They think it is ready to be made a WG item. Gorry: Faster Restart. What needs to happen before this can progress. What are the simulations that we need to do? * What are the dangers of congestion collapse, if any, or of periods of high loss, if many flows are doing this? * Is this good for the flow itself? What if packets are dropped? * Fairness with TCP? Jabber question: Does Faster Restart also apply to a flow after an underutilized period, not a just after a completely idle period. Sally: I would like it to apply to this also, but I don't remember if the draft includes that case or not. Colin: RTP and the DCCP draft. There are no known open issues. Question: Is Colin going to present this in AVT tomorrow morning? He doesn't know, but he will present it in AVT at some point. Sally: CCID4, draft-floyd-dccp-ccid4-00.txt. Next step: make it a working group document. It would be considered for Experimental. It won't be finalized until TFRC-SP is finished with IESG rview. Sally: CCID2 (no viewgraphs): Is there an interest in a slowly-responding variant of CCID 2, that is, AIMD with different increase and decrease parameters? Would be intended to go to Proposed Standard. Question: Who would use this? Answer: 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. Sally: 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. Question: What about small-packet variants, including TFRC-SP, on paths with very small MSS. Colin will send email about this. Question: How well would TCP work over these paths? Implementation Report: Ian is fixing bugs. Lars: They had a hard time figuring out which of the implementations they are using are standards comformant. The implementations don't seem to be based on reading the RFC, but seem to be based on the Sweden implementation. Report: There has been some comparisons between the Linux and FreeBSD implementations. Gorry: At the next meeting we would be happy to have more implementation reports, with slides. Drafts needing work: TFRC Media Guide, from Tom. This document is trying to discuss using DCCP from an application point of view. Are we ready to move forward on this? Yes, Tom should revise this document. A DCCP User Guide. Gorry: Don't read the current guide. This document is to give Guidance to users and implementors, not to address isssues related to CCIDs. Needed: firewalls, feature negotiation, service codes, APIs. Do we have an editor? The implementors would be a nice source for contributors. Service Codes: Joe Touch has an internet-draft on port names. The purpose of service codes is to identify applications to clients. Colin: One reason we aren't seeing service codes in implementations might be that applications don't want to be identified to middleboxes. Discussion of service codes: 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.
