http://permalink.gmane.org/gmane.ietf.dccp hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.dccp/1556 <pre>For me in particular - this wg is special - my career started out of this this..So thanks to my idol Sally Floyd, Gorry and all the others.. Regards Arjuna On 26 November 2012 09:24, Pasi Sarolahti &lt;pasi.sarolahti&lt; at &gt;iki.fi&gt; wrote: </pre> Arjuna Sathiaseelan 2012-11-26T09:28:46 http://permalink.gmane.org/gmane.ietf.dccp/1555 <pre>Many thanks to everyone also on my behalf, and particular thanks to Gorry and Colin who stepped in to finish the last draft! - Pasi On Nov 26, 2012, at 4:22 AM, Wesley Eddy wrote: </pre> Pasi Sarolahti 2012-11-26T09:24:12 http://permalink.gmane.org/gmane.ietf.dccp/1554 <pre>Hello, as you may have noticed, the RFC on UDP encapsulation of DCCP is now published, and there is nothing left to be done on the DCCP WG milestones list. I am going to ask for the Working Group to be closed. The necessary specifications have all been completed and are stable, and not much other activity on extensions, new CCIDs, etc seems to be going on, which would justify keeping the group chartered. Thanks to everyone who participated over the years to reach this state! After discussion with Pasi, we think it may be a good idea to leave the mailing list open for a year or so, in case there are any questions from people implementing and using DCCP. After then, we'll reassess whether leaving the mailing list available is having any value. Any new proposals for DCCP maintenance or extension should go to TSVWG (tsvwg&lt; at &gt;ietf.org). </pre> Wesley Eddy 2012-11-26T02:22:59 http://permalink.gmane.org/gmane.ietf.dccp/1553 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6773 Title: DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal Author: T. Phelan, G. Fairhurst, C. Perkins Status: Standards Track Stream: IETF Date: November 2012 Mailbox: tphelan&lt; at &gt;sonusnet.com, gorry&lt; at &gt;erg.abdn.ac.uk, csp&lt; at &gt;csperkins.org Pages: 20 Characters: 45073 Updates: RFC4340, RFC5762 I-D Tag: draft-ietf-dccp-udpencap-11.txt URL: http://www.rfc-editor.org/rfc/rfc6773.txt This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of </pre> rfc-editor< at >rfc-editor.org 2012-11-14T00:12:23 http://permalink.gmane.org/gmane.ietf.dccp/1552 <pre>The IESG has approved the following document: - 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' (draft-ietf-dccp-udpencap-11.txt) as Proposed Standard This document is the product of the Datagram Congestion Control Protocol Working Group. The IESG contact persons are Wesley Eddy and Martin Stiemerling. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ Technical Summary The document specifies a mechanism to encapsulate DCCP packets in UDP datagrams, to support NAT traversal through devices that do not support DCCP natively. It also discusses various interactions related to encapsulation, such as those related to MTU discovery or ECN processing, and interactions with higher level protocols. Working Group Summary The DCCP working group has been generally supportive of the document. It went through three working group last calls; starting on August 2010, February 2011, and April 2012. All WGLCs have been forwarded al</pre> The IESG 2012-08-22T15:08:05 http://permalink.gmane.org/gmane.ietf.dccp/1551 <pre>Ah, great, I see that you have picked up some (but not all) of my comments. New nits: </pre> Carsten Bormann 2012-06-25T22:51:29 http://permalink.gmane.org/gmane.ietf.dccp/1550 <pre> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Datagram Congestion Control Protocol Working Group of the IETF. Title : Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP) Author(s) : Tom Phelan Godred Fairhurst Colin Perkins Filename : draft-ietf-dccp-udpencap-11.txt Pages : 20 Date : 2012-06-25 Abstract: This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap Th</pre> internet-drafts< at >ietf.org 2012-06-25T17:52:23 http://permalink.gmane.org/gmane.ietf.dccp/1549 <pre> The IESG has received a request from the Datagram Congestion Control Protocol WG (dccp) to consider the following document: - 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' &lt;draft-ietf-dccp-udpencap-10.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf&lt; at &gt;ietf.org mailing lists by 2012-05-25. Exceptionally, comments may be sent to iesg&lt; at &gt;ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies an alternative encapsulation of the Datagram Congestion Control Protocol (DCCP), referred to as DCCP-UDP. This encapsulation allows DCCP to be carried through the current generation of Network Address Translation (NAT) middleboxes without modification of those middleboxes. This document also updates the SDP information for DCCP defined in RFC 5762. </pre> The IESG 2012-05-12T06:20:30 http://permalink.gmane.org/gmane.ietf.dccp/1548 <pre>Hi, I just requested publication of the dccp-udpencap draft. The write-up is shown below. Many thanks to Tom, Gorry and Colin for the hard work on the draft, and of course to everyone who reviewed it along the way! - Pasi ------------- (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested to be published as Proposed Standard. It specifies the mechanism for encapsulating DCCP headers in UDP datagrams, and does not outline an experiment. The type is properly indicated in the header. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary The document specifies a mechanism to </pre> Pasi Sarolahti 2012-04-26T11:02:31 http://permalink.gmane.org/gmane.ietf.dccp/1547 <pre>Hi, As people have noticed, not much has happened in DCCP WG for the several past months. However, we still should finish the last (recently updated) WG document, after which the working group is expected to be done. So: this Email starts the working group last call for "Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)" (draft-ietf-dccp-udpencap-10). The WGLC lasts two weeks and ends on Monday, April 16th. Please send possible comments to the dccp mailing list. For the udpencap document the last remaining issue, from the previous WGLC, has related to the text that speaks about negotiating the use of DCCP-UDP encapsulation, particularly in ICE. After discussing this with the authors, we concluded that coming up with a solid negotiation specification would still require significant amount of work and review cycles, and this is not worth delaying the document (and the WG) any further. Therefore, ICE negotiation is left for future work. If there is interest and energy, ne</pre> Pasi Sarolahti 2012-04-02T09:41:46 http://permalink.gmane.org/gmane.ietf.dccp/1542 <pre>Hi, Here is my review. I'm afraid I can't contribute much regarding Section 5 because I don't know enough about this stuff (but reading this was educational, it made me follow some references and print them :-) next time I'm equipped!). Anyway, it's good to see that this has already been commented on. I generally found the document well written, and I only found some nits, below - definitely no show-stoppers: - sec 3.4 par 1: s/implementations/implementation and: this paragraph sounds as if it's talking about a tunnel endpoint (because of the use of "transfer"), which the document otherwise is not. Also about sec 3.4: it would be good to give an example. When I read this, my first thought was "huh? Aren't *network layer* options meant for the *network layer* ?" On second thought, Quick-Start came to my mind (I suspect that was also on your mind) - so, as a service to the reader, it would help to just mention e.g. Quick-Start as an example. sec 3.8: "NAT/NAPT topologies" =&gt; did you really m</pre> Michael Welzl 2011-06-24T09:07:52 http://permalink.gmane.org/gmane.ietf.dccp/1540 <pre> See in-line on dccp-service-code. Gorry On Wed, 15 Jun 2011, Miguel A. Garcia wrote: [After re-reading this I note that this section speaks of "native" DCCP whereas there was an earlier suggestion that this should be called "DCCP-STD", Colin and I should ensure this is consistent in the next revision.] I suggest a couple of lines to be clear to anyone composing SDP: RFC 5762 [RFC5762] defines the "dccp-service-code" attribute whose purpose is to identify the intended service/application to process a DCCP connection request [RFC5595]. The "dccp-service-code" attribute is the same for both DCCP-STD and DCCP-UDP encapsulations. So, as soon as we have this, I think we can then finalise the text! Noted, will fix. Seems OK to me, I'll see if Colin agrees. </pre> Gorry Fairhurst 2011-06-16T07:42:12 http://permalink.gmane.org/gmane.ietf.dccp/1538 <pre>Hi, In DCCP WG we are soon concluding draft-ietf-dccp-udpencap ("Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)"). This draft has parts related to the work done in MMUSIC (especially Section 5), and it was presented in the MMUSIC meeting in last IETF. The authors have modified the text based on the input received, and we are now looking for volunteer(s) from MMUSIC to review whether the new text (mostly in Section 5) looks ok, before moving forward with the draft. The draft can be found at http://tools.ietf.org/html/draft-ietf-dccp-udpencap-08 - Pasi </pre> Pasi Sarolahti 2011-06-15T07:42:03 http://permalink.gmane.org/gmane.ietf.dccp/1537 <pre>Hi, On May 24, 2011, at 12:40 PM, Pasi Sarolahti wrote: I agree 100% with this. Let the app use e.g. a socket option of DCCP, or don't even expose it and try to automatically use it as a fallback without even telling the application. Cheers, Michael </pre> Michael Welzl 2011-06-12T07:43:46 http://permalink.gmane.org/gmane.ietf.dccp/1536 <pre>Hi Rémi, On May 18, 2011, at 8:22 AM, Rémi Denis-Courmont wrote: I can't see why the two pairs of ports should be in the same sockaddr_in structure. I'd assume a typical setup to be that DCCP applications continue work as normally using DCCP sockets, and UDP encapsulation is controlled in some other way (e.g., socket options as Colin suggested). What do others think? Do we need clarification about API issues? - Pasi </pre> Pasi Sarolahti 2011-05-24T10:40:43 http://permalink.gmane.org/gmane.ietf.dccp/1535 <pre>Dear All, Please find our latest paper entitled "TCP-Friendly Rate Control (TFRC) for bursty media flows " &lt; at &gt; http://www.sciencedirect.com/science/article/pii/S0140366411001551 Our paper presents an indepth analysis of RFC 5348 and Faster Restart and also concludes that Faster Restart is not needed. Regards Arjuna </pre> Arjuna Sathiaseelan 2011-05-24T00:48:49 http://permalink.gmane.org/gmane.ietf.dccp/1534 <pre> What do you need other than one new socket option to indicate that UDP encapsulation is to be used and to provide the port? I must be missing something, since the API doesn't seem difficult. </pre> Colin Perkins 2011-05-21T12:00:53 http://permalink.gmane.org/gmane.ietf.dccp/1533 <pre>On Wed, 18 May 2011 07:24:19 +0100, Colin Perkins &lt;csp&lt; at &gt;csperkins.org&gt; wrote: to I have no _sane_ ideas how to build an API that works with the current proposal, that's why I'm concerned. </pre> Rémi Denis-Courmont 2011-05-19T11:54:04 http://permalink.gmane.org/gmane.ietf.dccp/1532 <pre>Rémi, On 18 May 2011, at 06:22, Rémi Denis-Courmont wrote: How do you suggest we build a UDP encapsulation solution without using a second pair of ports? It would seem fundamental to the solution space. Do you want to propose an API? </pre> Colin Perkins 2011-05-18T06:24:19 http://permalink.gmane.org/gmane.ietf.dccp/1531 <pre>On Tue, 17 May 2011 21:56:52 +0100, Colin Perkins &lt;csp&lt; at &gt;csperkins.org&gt; wrote: a The concern is that we have two (pairs of) ports. This does not only not fit in the standard SDP m=line, but it does not fit in the traditional sockaddr_in/sockaddr_in6 abstraction (and its equivalent in many programming languages/frameworks). It might be that the API makes the problem go away, but that seems like a risky bet in the absence of any sketch of an API (it would not need to be normative). </pre> Rémi Denis-Courmont 2011-05-18T05:22:37 http://permalink.gmane.org/gmane.ietf.dccp/1530 <pre> What's the concern here? Use the IANA registered port, unless specified otherwise by the application. Any UDP tunnelling solutions must specify a UDP port. </pre> Colin Perkins 2011-05-17T20:56:52 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.dccp