Subject: Re: [MMUSIC] Getting the SDP right fordraft-ietf-dccp-udpencap-07.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 12 Apr 2011 14:24:44 +0300

Hi,

>> This is the one point on which I disagree -- this is a choice of
>> alternate transports, so it's more like ICE than CapNeg, it seems to me.
>>
> I think it depends on what you are trying to do: Negotiate use of a
> mechanism that both sides support or find a mechanism that can establish
> connectivity as verified by ICE. It's probably quite reasonable to
> support both scenarios. RFC 5939 Section 3.7 has a bit more text around
> this btw.
> 
> More discussion/opinions on this point would be useful.

theoretically, I agree there are two scenarios. However, in practice,
endpoints are interested in establishing the best possible connection.
ICE allows the endpoints to decide what "the best" means to them. It may
be the connection that can be established the fastest, or the connection
with the lowest delay, or whatever. Therefore, endpoints will try every
possible path until they find the best according to their definition.

Why would two endpoints want to limit themselves to only try
DCCP-over-IP paths or DCCP-over-UDP paths when they can try both and
pick the best? Do you have any scenario in mind where endpoints are
constrained to only try one type of path for some reason?

Cheers,

Gonzalo

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 14 Apr 2011 16:52:32 +0100

> constrained to only try one type of path for some reason?
 From a transport perspective, there could be things that are not 
immediately apparent: e.g. you may prefer IP encaps in some cases, if 
the app wanted to use ECN support, DCCP's Path MTU Discovery, Partial 
Checksum, etc these may all offer complete functionality via IP, but may 
not work (well) via UDP.

Gorry

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 14 Apr 2011 22:44:00 -0400

> constrained to only try one type of path for some reason?
I can make similar arguments for any choice of SDP "transport protocol", 
e.g. middleboxes may allow some transports/profiles, but not others, and 
hence we should always use ICE to just pick one that works. However we 
have recent examples that do not require ICE to negotiate different 
transports, e.g DTLS-SRTP (per RFC 5763), not to mention that CapNeg 
(RFC 5939) was motivated in large part by this use case.

At the end of the day, the question is whether we want to always mandate 
that ICE is implemented in order to negotiate different transports, or 
whether we stick with recommendations based on the scenario you are 
concerned with (negotiation or verified connectivity). RFC 5939 Section 
3.7 describes this trade-off, and I still believe it to be the correct 
one, and hence do not think we should mandate one way or the other.

Thanks

-- Flemming