At 10:23 AM -0800 3/3/08, 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.
Not all media, and not even all SIP-arranged media, are necessarily real time (if Jonathan gets TOTE through, to take one future, SIP could use TOTE for the delivery of any MIME object). Once the overlay built for this exists, I believe we can expect either generic storage or TOTE-like traversals to consider the overlay as a path of last resort. For some of those uses, the additional latency will not be the problem that it would be for real-time media. >Bruce: Can you comment on this? Reload-03 has no clear text on symmetric >routing for media. > >This is an important topic (though not directly related, so I have >changed the Subject name). > >All commercial products I know have some sort of two hop tunnel via a >media server as the path of last resort or openVPN. Tunnels were however >not presented in any I-Ds, since they violate the IT rules of using well >known ports. I don't know why openVPN is not an IETF standard. >http://en.wikipedia.org/wiki/OpenVPN > >Given the reticence of going public will stuff that IT organizations >don't like, I cannot volunteer any products names, but I know several >products using tunnels. > >Unless the IETF comes up with a better 100% sure way of NAT traversal, >tunnels will continue to be used in NAT traversal products. I don't think this is the right place to discuss generic mechanisms for NAT traversals, but I strongly agree that getting this right is going to be critical for any system to get real deployment. Just getting NAT traversal right for neighbors creates significant overhead in some topologies designed to reduce the hop count, and it makes the decisions around how to handle joins and leaves trickier than they look at first. Ted >A better solution would be HIP, but the nitty-gritty work and OS code >for HIP NAT traversal has not yes been published AFAIK. >If this is not accurate, HIP folks, please correct me. > >Thanks, Henry > >-----Original Message----- >From: Ted Hardie [mailto:[EMAIL PROTECTED] >Sent: Monday, March 03, 2008 9:46 AM >To: [EMAIL PROTECTED]; Henry Sinnreich >Cc: P2PSIP Mailing List >Subject: Re: [P2PSIP] Extending the (inclusive) merge for P2PSIP > >At 5:10 AM -0800 3/1/08, [EMAIL PROTECTED] wrote: >> >> > a. Churn can break the return path. For a example a 95% >probability >>> for success in the presence of churn over 10 hops each will result in >a >>> total probability of success of 099^10=0.59, that is 59%. The media >path >>> cannot work well if the two end points cannot see each other and >there >>> is no solution given here for the media path. Perhaps another media >>> relay or using HIP? This is a missing item. In any case the media >path >>> MUST NOT follow the symmetric search path since the delay will be >>> unacceptable over so many hops and unknown geographic locations that >can >>> be anywhere on the Internet. >>> >> >>Most people believe that media should never be routed across the >overlay >>regardless of the routing mode. TURN is assumed for deployments where >a >>direct connection can't be established, like regular SIP. > >I find statements like "media should never be routed across the overlay" >to be invitations to Murphy to muck things up. It's clear that the base >case should be that media should be routed directly between nodes where >possible. It's also clear that where a deployment provides adequate >infrastructure >(like TURN servers), using those is preferable to routing media over the >overlay. > >But never? Sorry, I'm more pessimistic than that. The overlay ends up >being >a path of last resort, and I have a strong suspicion that paths of last >resort always >get used sometime. The protocol document should be clear that it is a >last resort >and why, but I believe we need to provide guidance on how to use an >overlay as a media path. If we don't, it will get used in whatever way >is >easiest, with whatever consequences that entails. After some of the >recent >proposals, I can't even come up with a scenario I'm sure is parody. I >thought about suggesting TCP over DATA URIs, but I'm pretty sure >Jonathan >has a draft on that in the works..... > > Ted _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
