Subject: RE: [MMUSIC] Few comments on ICE-16

From: "Jean-Francois Mule" <[email-masked]>
Date: Mon, 2 Jul 2007 07:02:25 -0600

Dan Wing wrote:
> > - re: the new formula for Ta:
> > I understand that this came out of the ICE pacing discussion and
> Dan's
> > proposal on the TSVWG list and following discussions but
> > nonetheless, it adds significant complexity.
> 
> I don't believe it does; it merely defines a formula to calculate
> Ta and RTO, rather than using hard-coded values.  The STUN state
> machine stays the same, and ICE and ICE's operation do not interfere
> with the STUN state machine or STUN timers due to this change.

Ok, it is better than the hard-coded value given the intended benefits
but, as the ID is written, my understanding is that for each media
stream, the agent takes all the potential codecs to be offered, and for
all the associated ptimes, calculate the size of the RTP packet/stun to
compute Ta_i and for the sum.
May this is not "significant" given the benefits, but it still looks
more complex. 

> > 1) nit - while you point folks to read section B.1 for more
> > details, it
> > is a bit opaque as presented. Adding one sentence around this
> > formula's
> > goals (same bandwidth as RTP) or risks if implementers choose to
> > hardcode this as 20ms may help.
> > 2) what happens when you have a media stream being offered
> > with a codec
> > and different ptimes supported (e.g. G.711, ptime=10, 20)? Should an
> > implementation should the default ptime for the codec or the
> > ptime that will result in the greater sum value?
> 
> It's impossible for the offerer to send a connectivity check until
> it receives the SDP answer (because until the answer arrives, it
> doesn't know the IP address and UDP port to send its connectivity
> checks to).  When the answer arrives, the offerer will know which
> ptime to use.  
Yes.

> The RTO and Ta formulas are calculated at the time
> the answer is received (not when the offer is generated).
Well, nothing says so for Ta. The text in section 5.8 for RTO may
suggest that indeed but not for Ta.
 
May be it was my sequential reading of the ID that made me believe that
at this point in the ICE text(4.1.x), the requirements are only about
gathering candidates. In section 5.8 (about scheduling checks), some
text even says:
  | Ta is the same value used to
  | pace the gathering of candidates, as described in Section 4.1.1.

But no text actually forbids an agent to compute the Ta_i before SDP
negotiation as candidates are gathered.
May be the text for Ta should be moved or referenced elsewhere too
(section 6 and/or 9?).

Jean-Francois.

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 2 Jul 2007 10:20:28 -0700

> stream, the agent takes all the potential codecs to be 
> offered, and for all the associated ptimes,

It doesn't use the codecs or ptimes from the offer; rather, it uses 
the most-preferred codec and its ptime that was chosen by the 
answerer for its calculation.

> calculate the size of the RTP packet/stun to

Right, but there's no harm in doing it before -- you'll just not be
able to complete ICE faster if the answer chose a high-bandwidth
codec.  It's an implmentation decision on where you want to do
the calculation.  I don't see any advantage to doing it when you
build the offer (the Ta and RTO values aren't needed at that point, 
anyway), and there are disadvantages to doing the calculation at that
point in the call flow.

> May be the text for Ta should be moved or referenced elsewhere too

That might help; I'll leave that to Jonathan.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 18:19:19 -0400

inline.

Jean-Francois Mule wrote:
> Jonathan,
> 
>   Here are a few comments.
> 
> - in 4.1.1.2., paragraph 2:
> The current text puts 2 conditional MUSTs depending on the deployment
> usage but does not clearly spell out what MUST be implemented and
> configurable.
> As you did in the first paragraph, it would be a plus to have a clear
> requirement on what is RECOMMENDED for the agent to implement (SHOULD
> for both STUN Allocate & Binding). 

Sorry - I'm not seeing what part of paragraph 2 is relevant here. Can 
you point it out?

> I understand that this came out of the ICE pacing discussion and Dan's
> proposal on the TSVWG list and following discussions but nonetheless, it
> adds significant complexity.

Yes.

> 1) nit - while you point folks to read section B.1 for more details, it
> is a bit opaque as presented. Adding one sentence around this formula's

OK. I added some text explaining that the purpose was to make the ICE 
checks take the same bandwidth as the media.

> 2) what happens when you have a media stream being offered with a codec
> implementation should the default ptime for the codec or the ptime that
> will result in the greater sum value? 

Ah, this is a good point.

The Ta algorithm was primarily aimed at connectivity checks, where you 
have done the O/A exchange and thus know which codecs you are using. 
Here, when using it to pace gathering of candidates, you don't know yet. 
I think the right thing in this case would be to take the worst case and 
use that.

> 
> - RTO: consider removing "/" from the formula 

Yeah - this is confusing. Its not division. Will fix.

> 
> - what happens if an agent receives SDP with changes in the SDP that
> would have required an ICE restart but the sending agent did not change
> pwg/frag (not fully compliant or buggy implementation)? 

My general philosophy is to not specify in protocols behaviors when the 
other side has an implementation error. There are countless cases you 
could try and plan for.

> Should it reject
> the changes by sending an error response (which one)? or gracefully
> assume a restart and proceed with an ICE restart? does this impact the
> controlled/controlling role?
>  This could be clarified to handle the error case - may be it is and I
> missed it.

We should say nothing here. If an implementation can recover gracefully, 
excellent. Its a matter of local choice.

> 
> - re: IPv6, the email I sent to the v6 list on 5/24 and copied you
> Jonathan on asking for their review & guidance never made it to the v6
> list. I realized this today searching through the archive. I will update
> it and resend - sorry about that. Given the changes though, getting more
> eyeballs on the new text for dual-stack hosts will be a plus.

Yes, I saw your note. Thanks.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 03 Jul 2007 18:21:39 -0400

inline.

> May be the text for Ta should be moved or referenced elsewhere too

Actually, this is tricky since those values apply to both connectivity 
checks and to binding requests. There is no section currently common to 
both. I'm thinking of putting the formulas into an appendix, referenced 
from the main body. THis way the appendix can describe both cases.

-Jonathan R.