Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-tcp-09

From: "Alfred E. Heggestad" <[email-masked]>
Date: Wed, 13 Oct 2010 10:15:22 +0200

Review:

http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-09

draft-ietf-mmusic-ice-tcp-09

General comments:

* The additional candidate types specified in Section 5.3 and 5.4
   (NAT assisted, UDP tunneled) are they TCP only, or could they also
   be used for UDP transport? if the candidate types are generic enough
   it might make sense to split this out into a separate document,
   which could be used for both UDP and TCP.

* Each interface will gather 3 types of Host candidate:
   "active candidates, passive candidates, and simultaneous-open (S-O) candidates."
   this will increase the list of total candidates and candidate pairs,
   and also increase the complexity of the ICE stack. I think we should look
   at this strategy again, and try to come up with a better design. Could it
   be enough that each interface has 1 or 2 types of candidates (instead of 3) ?
   since the connectivity checks are timed, perhaps it could be enough
   to start with only 1 type, and only send TCP connects from the Controlling
   Agent.. this idea is not very well though through, but I still believe that
   it can be simplified..

* 5.4.  UDP-Tunneled Candidates

   it is not clear how these candidates are encoded. should it perhaps be
   encoded as server reflexive or relay candidates?

/alfred

---

From: Ari Keranen <[email-masked]>
Date: Wed, 13 Oct 2010 15:27:06 +0300

Hi Alfred,

Thanks for the review! Comments inline.

> which could be used for both UDP and TCP.

In this context they are TCP only, although I guess similar candidate 
types could be defined for UDP too. That said, I would not split them 
away from this document but rather make a new document for UDP if people 
think it would be worthwhile. Otherwise we'll end up with a normative 
reference to the new draft and would possibly delay this draft for quite 
some time for just a small gain.

> be enough that each interface has 1 or 2 types of candidates (instead of

In the spirit of ICE (gather and test everything) I think it makes sense 
to have all three types, even with the slight increase in complexity. 
And actually active and passive are not really two different types of 
candidates since you pair active only with passive and vice versa. Also, 
having all three types is only a SHOULD level requirement so an 
implementation that would prefer to have less can do so (with a risk of 
lower success ratio).

> Agent.. this idea is not very well though through, but I still believe that

It could be simplified, but AFAIK only at the expense of lower success 
ratio (or longer time-to-finish).

> encoded as server reflexive or relay candidates?

Good catch! I'd say this depends on the tunneling technique (whether the 
tunneled packets are relayed). We could add some text saying exactly 
that, or we could have a new candidate-type (say, "tunnel") in the SDP 
encoding defined in the ICE RFC:
http://tools.ietf.org/html/rfc5245#section-15.1

The SDP extension would be more explicit but would on the other hand 
require a bit more implementation effort. I don't have a strong opinion 
on this; probably either way is fine.

Cheers,
Ari

---

From: Simon Perreault <[email-masked]>
Date: Wed, 13 Oct 2010 08:37:03 -0400

> ratio (or longer time-to-finish).

For slower people like myself, could someone please explain *how* it
could be simplified?

Thanks,
Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Ari Keranen <[email-masked]>
Date: Wed, 13 Oct 2010 16:21:20 +0300

> For slower people like myself, could someone please explain *how* it

I guess you could use, e.g., a smaller amount of candidate types but 
with lower success ratio (say, if you use or implement only act-pass) or 
with worse performance (e.g., if you use only relayed candidates). I'm 
not aware of simplifications that would not have negative impact on 
performance though.

Cheers,
Ari