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

[Gorry Fairhurst <[e-mail]>]

On 12/04/2011 12:24, Gonzalo Camarillo wrote:
> 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 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