Subject: [tsv-area] RE: ICE pacing connectivity checks (wasRE:[MMUSIC] WGLC:draft-ietf-mmusic-ice-15.txt)

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Apr 2007 17:48:55 +0100

Dan,

All these calculations are a bit academic if they don't take into
account SIP forking. Suppose a SIP INVITE request containing an ICE
offer gets forked to 10 UASs, and each agrees to use ICE. There is then
10 times the amount of connectivity check traffic. The UAC might be on a
low bandwidth link, yet it has no control over the degree of forking
that might be encountered downstream.

John 

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: 26 April 2007 17:18
> To: [email-masked]
> Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] 
> WGLC:draft-ietf-mmusic-ice-15.txt)
> 
> (Jonathan had also listed this as ICE issue #11.)
> 
> I have moved discussion of ICE pacing to the tsv-area mailing list
> <https://www1.ietf.org/mailman/listinfo/tsv-area>, as the 
> tsv-area list is
> more appropriate for discussing TCP friendliness.  
> 
> My post to tsv-area
> <http://www1.ietf.org/mail-archive/web/tsv-area/current/msg00077.html>
> proposed new calculations for ICE's Ta and STUN's RTO.  These changes
> prevent ICE from exceeding the bandwidth RTP would have consumed.
> 
> -d
> 
> 
> > -----Original Message-----
> > From: Dan Wing [mailto:[email-masked]] 
> > Sent: Thursday, April 19, 2007 9:13 AM
> > To: 'Lars Eggert'; 'Magnus Westerlund'
> > Cc: [email-masked]
> > Subject: RE: ICE pacing connectivity checks (wasRE:[MMUSIC] 
> > WGLC: draft-ietf-mmusic-ice-15.txt)
> > 
> > I have created an Excel spreadsheet analyzing ICE's behavior 
> > compared to
> > RTP's behavior.  I am tweaking this spreadsheet and expect it 
> > to be useful
> > in helping us tune ICE's algorithms.  I want to make this a 
> > more useful
> > spreadsheet before sharing it; it doesn't quite do everything 
> > I like yet.  I
> > expect it will remain awkward to use, as I'm not an excel wizard.
> > 
> > In my initial analysis using this spreadsheet, I do agree 
> > that ICE's default
> > 20ms pacing and STUN's default 100ms retransmit timers are 
> > too aggressive if
> > we assume severely bandwidth-constrained links.  I expect 
> > that adjusting
> > these values based on the ptime, RTP packet size, STUN 
> > Request packet size,
> > and number of candidates will result in ICE behaving as well 
> > as RTP (with
> > RTCP feedback) in all cases, and better than RTP (with RTCP 
> > feedback) in
> > some cases.  The drawback of such tuning, however, is that 
> > ICE will take
> > longer to complete if there are many candidates.
> > 
> > -d
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Apr 2007 10:12:52 -0700

Do you have a suggestion?

-d

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 9:49 AM
> To: Dan Wing; [email-masked]
> Subject: RE: ICE pacing connectivity checks 
> (wasRE:[MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt)
> 
> Dan,
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Apr 2007 18:21:58 +0100

Well, perhaps the pacing needs to be adjusted according to the number of
simultaneous ICE sessions on a given interface, if bandwidth is believed
to be limited.

John 

> Sent: 26 April 2007 18:13
> To: Elwell, John; [email-masked]
> Subject: RE: ICE pacing connectivity 
> checks(wasRE:[MMUSIC]WGLC:draft-ietf-mmusic-ice-15.txt)
>

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Apr 2007 10:56:18 -0700

That could be done by calculating candidate_count to include all candidates
from all answerers - that would adjust Ta accordingly. 

That would help from the Offerer towards all of the forked endpoints, but it
wouldn't help in the opposite direction because the forked endpoints don't
know there are other forked endpoints.  It was that case (ICE checks from
answerers->offerer) I thought you were worried about.

-d

> Sent: Thursday, April 26, 2007 10:22 AM

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Apr 2007 20:03:05 +0100

True - it just shows that forking beyond modest levels (2-3 branches,
say) can be problematic.

John 

> Sent: 26 April 2007 18:56

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Apr 2007 12:40:39 -0700

Yep; but it's problematic for RTP, too, if early media is sent by the
branches.

-d

> Sent: Thursday, April 26, 2007 12:03 PM
> (wasRE:[MMUSIC]

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 27 Apr 2007 07:45:21 +0100

Yes, true. In fact ICE is probably less severe than early media, because
tests by UASs on those candidate-pairs that fail will not result in
traffic on the final hop to the UAC. Once STUN requests start reaching
the UAC, we should be close to terminating ICE for that particular
branch.

John 

> Sent: 26 April 2007 20:41