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

[Pasi Sarolahti <pasi.sarolahti@xxxxxx>]

Hi,

Because this is the only open DCCP document (and possibly the last  
DCCP document for the time being), I think it would be good to try to  
wrap it up pretty soon. Therefore, regarding the discussed issues I'd  
propose the following for consideration:

* Examples: I think it is a good idea to have a couple of sentences  
that tell to try DCCP-STD first and then move to DCCP-UDP if the  
connection establishment does not seem to work. I'm not sure if any  
more detailed examples are worth it to be included at this point, even  
though I see that they might be educating.

* Signaling the use of DCCP-UDP: if it is possible to define something  
straightforward about SDP without too much additional effort, then  
good. Alternatively, if the SDP part needs more thinking, it could be  
separated into a different document, that could be taken up for  
discussion for example in MMUSIC. Then this document would define just  
the UDP encapsulation and nothing else.

Thoughts? If the above is agreeable, then after making the few  
proposed modifications, I think it would be realistic to plan for a  
WGLC on the next version of the draft.

- Pasi


On Jul 6, 2010, at 8:55 AM, Phelan, Tom wrote:

> Hi Christian,
>
> Good input -- let me think about it a bit.
>
> Tom P.
>
> > -----Original Message-----
> > From: Christian Hoene [mailto:hoene@xxxxxxxxxxxxxxxx]
> > Sent: Monday, July 05, 2010 3:30 AM
> > To: Phelan, Tom; 'Colin Perkins'; 'DCCP working group'
> > Subject: RE:  I-D Action:draft-ietf-dccp-udpencap-01.txt
> >
> > Hello Tom,
> >
> > Some more examples on how to negotiated DCCP-in-UDP in the presence  
> > of
> > NATs would be surely helpful. For at least pointer to drafts and RFCs
> > which describe how to use them. Just for the bunch of implementers  
> > out
> > here, who might have to use this protocol.
> >
> >
> > Having two protocols (or even more) to select during connection
> > establishment would surely help to increase the reliability. For  
> > example,
> > try first DCCP, then DCCP-UDP, then TCP - or any other order as  
> > negotiated
> > with SDP.
> >
> > With best regards,
> >
> > Christian
> >
> >
> >
> > ---------------------------------------------------------------
> > Dr.-Ing. Christian Hoene
> > Interactive Communication Systems (ICS), University of Tübingen
> > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
> > http://www.net.uni-tuebingen.de/
> >
> >
> > -----Original Message-----
> > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On  
> > Behalf Of
> > Phelan, Tom
> > Sent: Wednesday, June 30, 2010 4:37 PM
> > To: Colin Perkins; DCCP working group
> > Subject: Re:  I-D Action:draft-ietf-dccp-udpencap-01.txt
> >
> > Hi Colin,
> >
> > Hmm, the SDP is the way it is because I was trying to follow one of  
> > your
> > earlier comments -- I thought not having a way to signal  
> > willingness to
> > do both -STD and -UDP encap was a little problematic, but as I recall
> > your comments you deliberately wanted it that way.  My initial take  
> > on
> > SDP allowed signaling either or both encaps, but you wanted to  
> > simplify
> > things.
> >
> > If you'd like to rethink the SDP, by all means do.
> >
> > Tom P.
> >
> > > -----Original Message-----
> > > From: dccp-bounces@xxxxxxxx [mailto:dccp-bounces@xxxxxxxx] On Behalf
> > Of
> > > Colin Perkins
> > > Sent: Wednesday, June 30, 2010 5:13 AM
> > > To: DCCP working group
> > > Subject: Re:  I-D Action:draft-ietf-dccp-udpencap-01.txt
> > >
> > > On 24 Jun 2010, at 20:15, Internet-Drafts@xxxxxxxx wrote:
> > > > 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 in UDP for NAT Traversal (DCCP-UDP)
> > > > 	Author(s)       : T. Phelan
> > > > 	Filename        : draft-ietf-dccp-udpencap-01.txt
> > > > 	Pages           : 11
> > > > 	Date            : 2010-06-24
> > > >
> > > > This document specifies an alternative encapsulation of the  
> > > > Datagram
> > > > Congestion Control Protocol (DCCP), referred to as DCCP-UDP.  This
> > > > encapsulation will allow DCCP to be carried through the current
> > > > generation of Network Address Translation (NAT) middleboxes without
> > > > modification of those middleboxes.
> > > >
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-ietf-dccp-udpencap-01.txt
> > >
> > >
> > > The encapsulation looks fine to me, but I have some concerns about  
> > > the
> > > SDP signalling:
> > >
> > > In an SDP offer, how can I signal that I support both native DCCP  
> > > and
> > > DCCP-in-UDP? This doesn't seem to be possible using the "a=dccp-in-
> > > udp" attribute, which "conveys no information about whether or not  
> > > the
> > > offerer is listening for DCCP-STD connections".
> > >
> > > How do I signal DCCP-in-UDP encapsulation in an ICE exchange? The  
> > > ICE
> > > "a=candidate:" lines in SDP use a transport protocol, not an
> > attribute.
> > > I wonder if it would it make more sense to register transports  
> > > such as
> > > DCCP/UDP/RTP/AVP, rather than using an attribute, to try to solve
> > > these issues? This is possibly something that should be raised in
> > > MMUSIC.
> > >
> > > --
> > > Colin Perkins
> > > http://csperkins.org/