Datagram Congestion Control Protocol (DCCP) WG TUESDAY, March 11, 2008 0900-1130 Morning Session I IETF-71, Philadelphia, USA WG Chairs: Thomas Phelan Gorry Fairhurst jabber: dccp@jabber.ietf.org Note-taker at IETF-71: Ingemar Johansson 1. Agenda Bashing No additional items were suggested for the Agenda. 2. Document Status The WG reviewed the document status, to-dos and milestones. There was one new WG I-D: draft-ietf-dccp-simul-open-00.txt RFC3448.bis will obsolete RFC 3448, proposed for PS and is now in WGLC. draft-ietf-dccp-rtp-07.txt is still in REF in the RFC-Ed queue waiting on RTP-mux, which is waiting on RTP-SSM. The WG milestones have been revised. The new milestones did not include work on draft-ietf-dccp-user-guide, since this was not active. Lars Eggert confirmed that this work was still within the Charter and that the WG was open to the arrival of new inputs (e.g. based on implementation work). 3. New Proposed Work None in this period. 4. Active WG Drafts * TCP Friendly Rate Control (TFRC.bis) (Sally Floyd, proxied by Chair) http://www.ietf.org/internet-drafts/draft-ietf-dccp-rfc3448bis-05.txt See presentation slides for details. This was currently in WGLC. There had been feedback from the list, more comments would be appreciated. Various minor changes, normative language and added implementation about X_recv_set. Gorry (as chair) said the specification of CCID-3 should evolve with changes in the throughput equation, but this did not say that a change in TFRC would update this. However, this document was close to CCID-3 on many issues. It was proposed that text would be added about relationship to CCID-3 and CCID-4 in the next revision, noting that the new RFC would update these. This was agreed. Lars Eggert: CCID-3 should be updated by 3448bis, please add the UPDATE line and a paragraph should be crafted and distributed via the list. The update would be handled by the RFC editor. Gorry: The text of CCID-4 could be updated once 3448bis is ready for the IESG. * Faster restart for TFRC (Sally Floyd, proxied by Chair) http://www.ietf.org/internet-drafts/draft-ietf-dccp-tfrc-faster-restart-05.txt See presentation slides for details. This document was based on TFRC. Evaluation needs to follow an agreed specification of TFRC (now in WGLC). There had been no changes since last IETF. Future simulations regarding impact on others, safe for internet, will focus on packet drops during faster restart. There were no comments from audience. * DCCP CCID4: TFRC with Small Packets (Sally Floyd, proxied by Chair) http://www.ietf.org/internet-drafts/draft-ietf-ccid4-02.txt The authors asked if this was ready for WGLC for Experimental. Implementation work had started. Gorry (as chair) noted that this depends on TFRC.bis, and it would be cleaner if this was updated following completion of the WGLC for TFRC.bis. * DCCP Service Codes (Gorry Fairhurst) http://www.ietf.org/internet-drafts/draft-ietf-dccp-serv-codes-04.txt Gorry presented a list of changes in the slides. Benchmarking security considerations had been added. Lars Eggert noted that you can not rate-limit benchmarking tools. Gorry would correct this text. Gorry reviewed the various IANA related text in the current draft. Policy regarding use of ports below 1024 was being updated in another draft in TSV. Lars Eggert: We should strive to conserve ports below 1024. Michelle Cotton: These are expected to require IETF Action in future for all transports. Gorry: This seems like the right way to also go for DCCP Ports. Gorry: One could argue that if the IETF had already decided on the use of a port for UDP or DCCP, then the equivalent port could be granted for DCCP at a lower bar. Michelle: We'd need to think. Above 1024, Expert Review was needed. Michele said this is not necessarily onersome - it depends upon the guidelines. Michele also noted that IANA proposes to reserve (but not allocate) a port number across all transports. Gorry: If say, the UDP reservation was made, could there be a case for an easier DCCP assignment for the same value? Lars; Could be so, we would need to work out the guidance. Gorry said we need to also sort out portnames/keywords (of size 14 Characters). There was a proposal to automatically derive this from the DCCP Service Code (e.g. see slides) - primarily motivated by the idea of automatic "free" assignment of ports. It was always possible to also do this via IANA registration. This did not preclude the use of a direct reservation to IANA. Tom noted that a human-readable format was good and DNS SRV records were discussed. The draft needs to be revised. The next step was to meet Michelle (IANA) and the ADs and check we have a consistent view of how the registries should be handled. The plan was to meet during IETF-71, to allow a new draft early the following week. It was hoped this would address comments. Gorry suggested if there was agreement this could progress to WGLC (or for further revisions if not). Tom said if the draft was finished it would be sent for WGLC. * DCCP Simultaneous-open Technique (Gorry Fairhurst) http://www.ietf.org/internet-drafts/draft-ietf-dccp-simul-open-00.txt This was now a WG work item. The document had been refined since the last IETF. Gorry highlighted a proposal for the timer to repeat DCCP-Listen packets. It needs people to read this and then the authors asked for a document freeze which could allow for it to be implemented (in Linux) and then could be WGLC'ed. 5. Implementor feedback * Implementing DCCP-TP (Tom Phelan) Tom Phelan had implemented a DCCP stack in user space for portability. This was a new implementation based on the specification. It was not based on a prior implementation. DCCP-TP currently provided a core DCCP layer using on DCCP in UDP encapsulation and CCID-2. Tom described issues he had encountered: There were a number of difficulties for implementers, lots of scattered text over various RFC's, difficult to tell normative from informative. The standards are not always implementation friendly (e.g ACK vectors) and in places are feature-rich, with some features highly complex. However, he had working code and was continuing. Pasi: We had also been doing some testing using Linux and has tested this partial implementation with an early Linux implementation and it had worked. Gorry: There could also be interest in interoperability testing among different implementations - not necessarily to progress DCCP to DS, but also to gain experience and then promote the new work to the wider community. Gorry noted GStreamer Plugin 2.0 had been announced and was now available for use. Remi said VLC also provides DCCP support. 6. Individual Submissions * IANA Allocation Guidelines (presented in TSV WG) http://www.ietf.org/internet-drafts/draft-cotton-tsvwg-iana-ports-00.txt Michelle had already presented her slides in TSVWG, but helped record what was proposed for the UDP and TCP registries. * Quick-Start for DCCP: http://www.ietf.org/internet-drafts/draft-fairhurst-tsvwg-qs-02.txt The draft had not changed. The authors propose to review this in the light of TFRC.bis. Could this be made a WGLC? Lars: This may be possible, if there were reviewers and energy. Tom: I think we should do the revision and take this to the list, if there is interest we could proceed to adopt as a WG item. * BEHAVE for DCCP (Remi Denis, 10 min) (to be confirmed) http://www.ietf.org/internet-drafts/draft-denis-behave-nat-dccp-01.txt Remi reviewed the draft. He said he believed that for DCCP NATs MUST NOT implement ALGs, in contrast to the SHOULD NOT for TCP, because DCCP streams were not reliable. There was a proposal that NAT must not change DCCP Service Codes. Tom: I agree with this. Gorry: I also accept this, and can update the Service Code draft to reflect this; we should say this in the behave document too. Remi asked about what was intended for partial checksums? Gorry: I think these MUST NOT be changed, if you want the application to behave correctly. If you knew there had been no corruption upstream, then you could increase the coverage, but I can't see how you would know this., * DCCP/UDP (Tom Phelan, 20 min) http://www.ietf.org/internet-drafts/draft-phelan-dccp-natencap-00.txt Tom presented the draft and noted this was an individual submission. There was discussion around the DCCP partial checksum. Tom said the intention was to use a zero UDP checksum, since this was already widely used in VoIP networks. Gorry: Partial checksums may be an issue, since they imply cross-layer signaling between the transport and link-layer to tell the link what to do. If we hide the coverage within the UDP payload this becomes hard. This is one facet of tunneling rather than native encapsulation. Gorry: I am not convinced that this is the best way forward. A generic UDP-tunneling approach may be better because other protocols face the same problem. Intention to make a new version of draft. Lars asked about interest to contribute to a more generic UDP tunnel approach that could be used to support a range of transports. Tom concluded by saying he would continue work on the draft. The meeting concluded and the WG would next meet at IETF-71.