Subject: Re: [P2PSIP] Routing discussion slides for this week's session

From: jiangxingfeng 36340 <[email-masked]>
Date: Tue, 04 Dec 2007 15:52:49 +0800

> 
> It is likely that peers will publish their address candidates 
> (host, 
> server-reflexive, and relay) in the overlay. Peers using iterative 
> routing 
> can send parallel copies of the request to the host, server-
> reflexive, and 
> relay address of the next hop. If the address candidates of the 
> next 
> hop are not available, then a CONNECT-like offer/exchange 
> mechanism can be 
> used.
> 
Does it mean that ICE procedure will be involved in the iterative routing mode? If it does, the latency will be unacceptable.

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

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Tue, 4 Dec 2007 00:30:07 -0800

> Does it mean that ICE procedure will be involved in the iterative routing mode? If it does, the latency will be unacceptable.

As I understand it, the proposal in P2PP is to essentially have what
would be the candidate addresses in ICE stored in the overlay, so that
as soon as you learn about another peer, you can try to connect to
them directly, without ICE.  I'd be very interested in further work
evaluating such ideas.  We've thought about this some, and reload-01
explicitly supported listing multiple addresses for each peer, but
there are a lot of tradeoffs in terms of additional protection needed
for the messages and demultiplexing, hop-by-hop ACKs (which I think
p2pp uses for normal communication), and additional latency if you
don't simply try all options in parallel/wasted messages if you do.
But, I do like avoiding the latency of ICE setup, so I think it's an
option that needs to be looked at carefully.

Bruce