Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Mar 2011 14:29:55 +0100

It seems the esteemed chairs have awarded me some time in Prague to discuss this - if we are going to have a meaningful discussion there, let's get the discussion going on the list first. So far I heard only from Christer.

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 07 February 2011 15:02
> To: mmusic
> Subject: Draft-elwell-ice-updated-offer (was RE: [MMUSIC] Yet 
> another alternative to ICE)
> 
> In response to Gonzalo's request for a better understanding  
> of the issues that keep ICE from being widely deployed, I 
> have submitted a new I-D on problems arising from the updated 
> SDP offer that ICE requires under some circumstances:
> https://datatracker.ietf.org/doc/draft-elwell-mmusic-ice-updated-offer/
> 
> Comments welcome.
> 
> John
> 
> 
> > -----Original Message-----
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Gonzalo Camarillo
> > Sent: 04 December 2010 20:33
> > To: Flemming Andreasen
> > Cc: [email-masked]; Kaynam Hedayat; 
> > [email-masked]; mmusic
> > Subject: [MMUSIC] Yet another alternative to ICE WAS (Re: 
> > draft-ietf-mmusic-media-loopback-14 review and comments)
> > 
> > Hi,
> > 
> > >> - NAT Traversal and usage of ICE
> > >>
> > >> [Authors] As Hadriel mentioned, if you have ICE you 
> don't need the
> > >> loopback primer. As he also clarified, the loopback situation is
> > >> different from standard calls because the mirror will 
> never send a
> > >> packet until it receives something from the source. This 
> > is certainly
> > >> possible for a regular call and calls may fail for that 
> reason, but
> > >> the loopback draft is dead without a solution for this problem.
> > >> Remember that the primary use case for this draft is 
> > service providers
> > >> wanting to test to subscriber devices that are almost 
> always behind
> > >> NATs. The proposed solution meets the requirements for 
> the dominant
> > >> use case and while standard solutions are certainly usable 
> > when they
> > >> are available, the unfortunate reality is that most of 
> them are not
> > >> implemented. We can add clarification text that if available ICE
> > >> should be used instead of the loopback primer method.
> > >>
> > > Thanks. The draft will also need to clearly explain how 
> the loopback
> > > primer would work, and in particular what the underlying 
> > assumptions are
> > > (e.g. latching) as well as when it will not work (e.g. when 
> > both source
> > > and mirror are behind a NAT, when you have overlapping 
> > IP-addresses and
> > > ports, etc). In short, the limitations of this approach 
> > must be clearly
> > > documented.
> > > 
> > > I will also check with our AD as to whether there are any 
> additional
> > > concerns with specifying such a solution when we already 
> > have ICE as the
> > > Standard.
> > 
> > as you all know, there have been a number of proposals to 
> standardize
> > simpler-than-ICE NAT traversal solutions that would only work 
> > in certain
> > scenarios or circumstances. There have been a lot of 
> > discussions around
> > them. A couple of IETFs ago there was even a bar BOF where 
> > people tried
> > to understand the issues that kept folks from deploying ICE in some
> > scenarios. I know there have been off-list follow ups on those
> > discussions but no draft have been submitted yet, AFAIK.
> > 
> > So, we need to frame this discussion taking into account the 
> > big picture
> > of NAT traversal and ICE. In this case, we need to understand 
> > the issues
> > that keep ICE from being widely deployed and, if needed, specify a
> > general solution to address those issues. Coming up with several
> > different NAT traversal mechanisms that only work in specific 
> > conditions
> > does not seem like the best outcome we can wish for.
> > 
> > I encourage people who are working on those ICE-related issues to
> > participate in this discussion because this is an important area.
> > 
> > Thanks,
> > 
> > Gonzalo
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mmusic
> >

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 17 Mar 2011 10:01:02 -0400

Hi John, 

Is the real issue that any updated offer is bad for faxes? I wonder if the scope needs to be extended to include:
- reINVITE at the end of a SDPcap neg. offer/answer (although IIRC the spec says the reINVITE is a SHOULD)
- what I term a "defensive" reINVITE (e.g. UA offers a long list of CODECs and after seeing the answer sends a new offer with only one CODEC so that it does not need to support on the fly CODEC changes)

Of the two remedies you propose, I favour the delay the fax updated offer - but I agree it is not fool-proof. 

Cheers, 

Peter Musgrave

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 17 Mar 2011 15:49:24 +0100

Peter,

Yes, since the draft was written it was brought to my attention that SDP cap-neg has a similar unfortunate interaction with fax (although it is only a SHOULD - ICE is a MUST), and I guess also your "defensive" re-INVITE. And likewise these can interact with 3PCC.

Delaying the fax updated offer might address ICE, but would be somewhat more difficult with the SDP cap-neg and "defensive" cases because you don't know for sure an updated offer will arrive. It would require some practical measurements with different delay values to see how effective it would be.

Rather than keep adding to the cases where an updated offer needs to be sent (we originally had fax and "defensive", now we have added ICE and cap-neg) it would be better if we could avoid the need. It seems the need arises only from certain classes of SIP/SDP-aware middleboxes, and I wonder in how many circumstances the updated offer will make the difference between the session not working and working. It strikes me that endpoints implementing these new capabilities are required to do too much to get through SIP-aware middleboxes that should be transparent but are not.

John

> From: Peter Musgrave [mailto:[email-masked]] 
> Sent: 17 March 2011 14:01
> To: Elwell, John
> Cc: mmusic
> Subject: Re: [MMUSIC] Draft-elwell-ice-updated-offer
> 
> Hi John, 
> 
> Is the real issue that any updated offer is bad for faxes? I 
> wonder if the scope needs to be extended to include:
> - reINVITE at the end of a SDPcap neg. offer/answer (although 
> IIRC the spec says the reINVITE is a SHOULD)
> - what I term a "defensive" reINVITE (e.g. UA offers a long 
> list of CODECs and after seeing the answer sends a new offer 
> with only one CODEC so that it does not need to support on 
> the fly CODEC changes)
> 
> Of the two remedies you propose, I favour the delay the fax 
> updated offer - but I agree it is not fool-proof. 
> 
> Cheers, 
> 
> Peter Musgrave
> 
> 
> > It seems the esteemed chairs have awarded me some time in 
> Prague to discuss this - if we are going to have a meaningful 
> discussion there, let's get the discussion going on the list 
> first. So far I heard only from Christer.
> > 
> > John
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 29 Mar 2011 21:56:54 -0400

Sorry I hadn't noticed this email response before (you changed the subject :)

Comments inline...

On Dec 4, 2010, at 3:33 PM, Gonzalo Camarillo wrote:

>>> [Authors] As Hadriel mentioned, if you have ICE you don’t need the
>>> different from standard calls because the mirror will never send a
>>> packet until it receives something from the source. This is certainly
>>> possible for a regular call and calls may fail for that reason, but
>>> Remember that the primary use case for this draft is service providers
>>> wanting to test to subscriber devices that are almost always behind
>>> NATs. The proposed solution meets the requirements for the dominant
>>> use case and while standard solutions are certainly usable when they
>>> are available, the unfortunate reality is that most of them are not
>> Thanks. The draft will also need to clearly explain how the loopback
>> primer would work, and in particular what the underlying assumptions are
>> (e.g. latching) as well as when it will not work (e.g. when both source
>> and mirror are behind a NAT, when you have overlapping IP-addresses and
>> ports, etc). In short, the limitations of this approach must be clearly
>> documented.
>> 
>> I will also check with our AD as to whether there are any additional
>> concerns with specifying such a solution when we already have ICE as the
>> Standard.
> 
> as you all know, there have been a number of proposals to standardize
> simpler-than-ICE NAT traversal solutions that would only work in certain
> scenarios or circumstances. There have been a lot of discussions around
> them. A couple of IETFs ago there was even a bar BOF where people tried
> So, we need to frame this discussion taking into account the big picture
> of NAT traversal and ICE. In this case, we need to understand the issues
> different NAT traversal mechanisms that only work in specific conditions

1) While it's always nice to have general solutions to problems, I think it's unfair to make media-loopback go back the drawing board and wait for some new ICE-ish mechanism that hasn't even been proposed yet.  The first loopback draft was submitted in December 2004!! (wow)

2) I know this isn't an IAB-approved argument, but protocol history consistently shows that a simple incremental solution to fixing the problem at hand invariably beats out a more complicated holistic solution to fix all possible problems people don't yet have.  By "beats out" I mean succeeds in getting adopted/implemented/used.  

3) Let's suppose we come up with a new NAT traversal solution alternative to ICE, or some form of ICE-Lite which is actually/truly Lite, which I'll call "NICE" for now.  Since lots of people don't have a problem with NAT traversal today for normal calls because they've solved it some other way, they won't need or even want NICE - their deployment ain't broken, so they won't want to fix it.  But they'll still want loopback.  Are we saying that in order to loopback test their SIP calls, they have to change their network to NICE even for normal calls that aren't broken today?  

4) One of the goals of loopback type testing is to make it as similar to a normal call as possible.  If the loopback call uses some NICE algorithm and connectivity checking to choose from multiple paths or go through a TURN server, and normal calls don't, the loopback test results are misleading.  And before anyone says "then make all calls use NICE"... that's the tail wagging the dog - people don't change their whole network for loopback testing, loopback testing has to fit itself in deployed networks.

My 4 cents, fwiw.

-hadriel

---

From: Riccardo Bernardini <[email-masked]>
Date: Wed, 30 Mar 2011 11:17:28 +0200

2010/12/4 Gonzalo Camarillo <[email-masked]>

> participate in this discussion because this is an important area.

Hi,
a question somehow related with this point: does someone know the order of
magnitude of the time required to complete an ICE procedure? (possibly
partitioned in the two components : time for candidate collection + time for
checks).  I am asking because NAT traversal is of some interest also in P2P
streaming and long times could be a problem in high churn situations.  Could
long times be an obstacle to ICE deployment even in other contexts?

---

From: Adrian Georgescu <[email-masked]>
Date: Wed, 30 Mar 2011 11:54:05 +0200

Hi,

What we learned when deploying Blink with ICE enabled by default:

- Some SIP ALG implementations caused broken call flows, some NAT routers even reset ! when an ICE proposal was detected 
- The SIP packet size was to large when using UDP for some NAT routers,  because of fragmentation issues
- For PSTN calls, media always go through operator servers, commercial SIP service providers do not care much about ICE

ICE itself works fine, is the fact that most SIP deployments are using UDP transport that makes things behave unreliable. If UDP transport would be deprecated and TLS made mandatory all these problems would not exit as no SIP ALG will temper with the SIP packets and the packet size would not matter.

So we turned ICE off by default to avoid complaints.

Regards,
Adrian

On Mar 30, 2011, at 11:17 AM, Riccardo Bernardini wrote:

> a question somehow related with this point: does someone know the order of magnitude of the time required to complete an ICE procedure? (possibly partitioned in the two components : time for candidate collection + time for checks).  I am asking because NAT traversal is of some interest also in P2P streaming and long times could be a problem in high churn situations.  Could long times be an obstacle to ICE deployment even in other contexts?
>  
> 
> Thanks,
> 
> Gonzalo