On Mar 3, 2008, at 1:23 PM, Henry Sinnreich wrote:

> Ted,
>
>> The overlay ends up being a path of last resort
>
> Having the media go over 5-10 hops, some of which may pass via several
> continents due to the hashing in the DHT makes such real time media
> worthless due to the delay and cut-offs.
>
> Bruce: Can you comment on this? Reload-03 has no clear text on  
> symmetric
> routing for media.
>

I think that's because we assume a TURN server will be used, if  
necessary.  I'm somewhat in Ted's camp of "it will be used as a last  
resort, regardless of what the draft says" although I think some of  
my fellow authors would like to require that implementors explicitly  
prevent it from happening.

With that said, I would say that if you did really, really want to  
relay media through an overlay:

- compress the path as much as possible, i.e. add an edge to the  
connection table that reduces the number of hops to the lowest number  
possible

- implement route optimizations.  Ordinarily I oppose routing options  
other than symmetric because of the complexity involved with the need  
to have fallbacks to symmetric for various healing/joining  
scenarios.  But if you're going to insist on routing media across an  
overlay, you're going to have to pay the complexity cost of fancier  
routing.


I think Henry's point that geography comes into play is very  
important here.  Henning has proposed that AS number be included in  
selection of a TURN server.  It's not clear to me that is the right  
rule in all cases or that  we have a working example of how to really  
implement this that isn't far too researchy at this point, but we  
might have some hope of doing it for TURN service discovery.  Most of  
the DHT proposals I think we've seen for P2PSIP have tried to avoid  
the complexity of using something like PASTRY.

I really want to leave this out of scope for now, except for the TURN  
service discovery portion.  Just too much complexity and too many  
headaches for little gain.

Bruce


_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to