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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/
> >>>
> >>>
> >




[Index of Archives]     [Linux Kernel Development]     [Linux DCCP]     [IETF Annouce]     [Linux Networking]     [Git]     [Security]     [Linux Assembly]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [DDR & Rambus]

  Powered by Linux