Hi Pasi, This sounds like a good plan overall. See inline for more... Tom P. > -----Original Message----- > From: Pasi Sarolahti [mailto:pasi.sarolahti@xxxxxx] > Sent: Wednesday, July 07, 2010 12:45 AM > To: Phelan, Tom > Cc: Christian Hoene; Colin Perkins; DCCP working group > Subject: Re: I-D Action:draft-ietf-dccp-udpencap-01.txt > > 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. > [Phelan, Tom] That sounds good. Too much will open a can of worms that's probably not worth opening. > * 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. > [Phelan, Tom] I think we can clean up the SDP with some minor changes. > 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. > [Phelan, Tom] When do we want the next version? I could have it before the upcoming meeting, but not before the draft deadline, which I assume is either this coming Monday or has already passed. > - 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/ > >>> > >>> > >
