headers
Pasi Sarolahti | 26 Nov 2012 10:24
Picon
Picon
Favicon
Gravatar

Re: closing DCCP WG

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:

> 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 <at> ietf.org).
> 
> -- 
> Wes Eddy
(Continue reading)

Permalink | Reply | 1 comment |
headers
Wesley Eddy | 26 Nov 2012 03:22

closing DCCP WG

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 <at> ietf.org).

--

-- 
Wes Eddy
MTI Systems
Permalink | Reply | 0 comments |
headers
rfc-editor | 14 Nov 2012 01:12
Favicon

RFC 6773 on DCCP-UDP: A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal


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 <at> sonusnet.com, 
                    gorry <at> erg.abdn.ac.uk, 
                    csp <at> 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 those middleboxes.  This document also updates the
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 22 Aug 2012 17:08
Picon
Favicon

Protocol Action: 'Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)' to Proposed Standard (draft-ietf-dccp-udpencap-11.txt)

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 also to TSVWG working group, and the
second WGLC was announced in MMUSIC working group. During the
first WGLC, various technical fixes were proposed. The second
(Continue reading)

Permalink | Reply | 0 comments |
headers
internet-drafts | 25 Jun 2012 19:52
Picon
Favicon

I-D Action: draft-ietf-dccp-udpencap-11.txt


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dccp-udpencap-11

A diff from previous version is available at:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-dccp-udpencap-11

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)

Permalink | Reply | 1 comment |
headers
The IESG | 12 May 2012 08:20
Picon
Favicon

Last Call: <draft-ietf-dccp-udpencap-10.txt> (Datagram Congestion Control Protocol (DCCP) Encapsulation for NAT Traversal (DCCP-UDP)) to Proposed Standard


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)'
  <draft-ietf-dccp-udpencap-10.txt> 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 <at> ietf.org mailing lists by 2012-05-25. Exceptionally, comments may be
sent to iesg <at> 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dccp-udpencap/ballot/

No IPR declarations have been submitted directly on this I-D.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi Sarolahti | 26 Apr 2012 13:02
Picon
Picon
Favicon
Gravatar

Publication requested for draft-ietf-dccp-udpencap-10

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 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Pasi Sarolahti | 2 Apr 2012 11:41
Picon
Picon
Favicon
Gravatar

WGLC for draft-ietf-dccp-udpencap-10

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,
negotiation can be specified in a separate document, probably in a different working group.

- Pasi
Permalink | Reply | 0 comments |
headers
Pasi Sarolahti | 15 Jun 2011 09:42
Picon
Picon
Favicon
Gravatar

Reviewing draft-ietf-dccp-udpencap

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
Permalink | Reply | 5 comments |
headers
Pasi Sarolahti | 24 May 2011 12:40
Picon
Picon
Favicon
Gravatar

Re: Fwd: I-D Action: draft-ietf-dccp-udpencap-08.txt

Hi Rémi,

On May 18, 2011, at 8:22 AM, Rémi Denis-Courmont wrote:

> On Tue, 17 May 2011 21:56:52 +0100, Colin Perkins <csp <at> csperkins.org>
> wrote:
>> 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.
> 
> 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).

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
Permalink | Reply | 1 comment |
headers
Arjuna Sathiaseelan | 24 May 2011 02:48
Picon
Picon

Paper on TFRC evaluation for bursty traffic

Dear All,
  Please find our latest paper entitled "TCP-Friendly Rate Control
(TFRC) for bursty media flows "  <at> 
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
Permalink | Reply | 0 comments |

Gmane