Subject: [AVT] draft-ietf-avt-ecn-for-rtp-03

From: Cullen Jennings <[email-masked]>
Date: Sat, 6 Nov 2010 18:14:15 -0600

Nice work - I like it. 

My preference would be to have just one way to see if ECN worked  instead of having three. Having three just seems like sure way to reduce interoperability. Of the three, I would choose ICE but the real issue in my mind let's choose 1 not 3.

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 07 Nov 2010 10:51:03 +0800

Hi Cullen,

Yes, I would also have preferred a single Initiation mechanism. However,
depending on your application this is not completely practical. If we
are going to select only one, then I personally would say that it is the
one using probing. Because ICE doesn't work in multicast. Leap of faith
has a pretty bad failure mode. Bob Briscoe seems to favor only leap of
faith.

I don't think we are sufficiently clear on what needs to implement. When
it comes to initiation methods I think we should make the mandating
clear. Leap of faith is no extra functions, only the possibility to jump
into usage, thus I think this can be mandated to support. The probing
phase is needed as a fall back so that needs to be the common supported
solution in my view. I think it makes lot of sense to mandate ICE
probing if you are using ICE for the session setup.

Comments and feedback on the above proposal?

Cheers

Magnus

Cullen Jennings skrev 2010-11-07 08:14:
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Sun, 7 Nov 2010 12:35:24 +0800

On 7 Nov 2010, at 10:51, Magnus Westerlund wrote:
> Yes, I would also have preferred a single Initiation mechanism. However, depending on your application this is not completely practical. If we are going to select only one, then I personally would say that it is the one using probing. Because ICE doesn't work in multicast. Leap of faith has a pretty bad failure mode. Bob Briscoe seems to favor only leap of faith.
> 
> I don't think we are sufficiently clear on what needs to implement. When it comes to initiation methods I think we should make the mandating clear. Leap of faith is no extra functions, only the possibility to jump into usage, thus I think this can be mandated to support. The probing phase is needed as a fall back so that needs to be the common supported solution in my view. I think it makes lot of sense to mandate ICE probing if you are using ICE for the session setup.
> 

The RTCP extensions to allow a receiver to provide ECN feedback MUST be implemented. I agree that senders MUST implement RTCP-based probing: it may be slow, but it's the only choice that works in all cases. 

I don't think we need to mandate support for leap-of-faith: it's a local choice for the sender, with no interoperability concerns (since it needs no receiver changes). To me, that makes it OPTIONAL at the sender.

Regarding the ICE probing phase, do we have any intuition how likely this is to break non-extended STUN servers? Would it make sense to say SHOULD probe using ICE, but fallback to RTCP-based probing if that fails?

-- 
Colin Perkins
http://csperkins.org/

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 00:55:32 -0600

How about... 

For application that do multicast, you do probing and for applications that are only unicast, you do ICE. 

I see the merits of your proposal. I have not thought about this enough to consider all the implications. This is going to be tricky and no matter what we choose it not going to be easy to get this to deploy given the usual chicken/egg problem of who implements this first, the apps or the network.

---

From: Magnus Westerlund <[email-masked]>
Date: Sun, 07 Nov 2010 15:06:55 +0800

> For application that do multicast, you do probing and for applications that are only unicast, you do ICE. 

I think you are a bit to much assuming that RTP based applications are
using ICE. That does not appear to be the truth for a number of
applications. Thus I think using unicast as gating is not the right one.
> I see the merits of your proposal. I have not thought about this enough to consider all the implications. This is going to be tricky and no matter what we choose it not going to be easy to get this…

We have a buyer in 3GPP that wants ECN for RTP and it is already in
their specs for IP handling. They are going to use the leap of faith
method for initiation as they think they can trust their network to not
do bad things with ECN marked packets. Thus relying on end-point
signaling if they handle ECN or not.

Cheers

Magnus Westerlund

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sun, 7 Nov 2010 08:24:28 +0100

At the end of the day ICE is still optional, and to me this is an orthogonal issue to what ICE was designed to do. It would therefore appear to me to be inappropriate to start mandating ICE left right and centre just because it forms one way of developing a solution.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Magnus Westerlund
> Sent: Sunday, November 07, 2010 7:07 AM
> To: Cullen Jennings
> Cc: IETF AVT WG
> Subject: Re: [AVT] draft-ietf-avt-ecn-for-rtp-03
> 
> > For application that do multicast, you do probing and for 
> applications that are only unicast, you do ICE. 
> 
> I think you are a bit to much assuming that RTP based 
> applications are using ICE. That does not appear to be the 
> truth for a number of applications. Thus I think using 
> unicast as gating is not the right one.
> > 
> > I see the merits of your proposal. I have not thought about 
> this enough to consider all the implications. This is going 
> to be tricky and no matter what we choose it not going to be 
> easy to get this to deploy given the usual chicken/egg 
> problem of who implements this first, the apps or the network. 
> 
> We have a buyer in 3GPP that wants ECN for RTP and it is 
> already in their specs for IP handling. They are going to use 
> the leap of faith method for initiation as they think they 
> can trust their network to not do bad things with ECN marked 
> packets. Thus relying on end-point signaling if they handle 
> ECN or not.
> 
> Cheers
> 
> Magnus Westerlund
>