80 likes | 93 Views
This discussion explores different P2PSIP routing techniques such as iterative, recursive, semi-recursive, and symmetric/asymmetric, and aims to determine a set for protocol implementation. The focus is on NAT traversal and the impact on routing decisions.
E N D
P2PSIP Routing Discussion(“Routing: what does it look like?) Spencer Dawkins (spencer@mcsr-labs.org) IETF 70 – December 2007 Vancouver, British Columbia
Goal (from the agenda) • How many routing techniques do we need, and can we pick a set? • Discuss/compare different routing techniques (iterative, recursive, semi-recursive, as well as symmetric vs. asymmetric). • Can we decide on a set for the protocol to implement?
Routing mode high-level overview • Assume at least enough paths to form an overlay • Predecessor, successors, finger table • Peers can set up more paths as optimizations • What do you do with the extra paths? • Iterative – peer gets not-for-self request and redirects • Recursive – peer gets not-for-self request and forwards • Semi-recursive – recursive request, return responses directly • Strict Forwarding – responses continue around overlay • Related topic about responses • Same path as request (symmetric or asymmetric)? • What modes make sense? • Does more than one mode make sense?
Since IETF 69 • CONCEPTS didn’t discuss routing specifics • Left decisions about paths to DHT specifics (Chord …) • RELOAD-01 described four routing mechanisms • Iterative, recursive, semi-recursive, strict forwarding • RELOAD-02 is down to two • Dropped “semi-recursive” and “strict forwarding” • Recent focus on recursive/symmetrical routing • Mostly due to NAT traversal concerns
High-Order Bits (Spencer’s opinion) • We have four categories of request routing • Lots of list traffic discussing recursive/semi-recursive • NAT traversal is driving the discussion • Iterative, Semi-recursive, Asymmetric all penalized • “… but you might not be able to open a connection” • Much less discussion of other aspects • Performance, latency, fairness, robustness, debugging • If you care about these topics, start talking!
Last week was an interesting week… • Dean Willis - P2PSIP intermixing two topics • SIP “finding” – figuring out where to send a request • SIP “routing” – forwarding a request that’s not for you • Three possibilities • GET location, SEND request that P2P routes • GET location, send to that location (P2P does not route) • SEND request (P2P determines location) • Unsolved mysteries • Do we need proxy-ish policy enforcement? • Do we need proxy-ish support for multiple devices, etc? • Are peers turning into Ad Hoc routers? Through NATs?
A Few Words From Your Sponsor… • It would be great if we all agreed on a few things • Are overlays big enough to require SPF routing? • Some scenarios with “thousands” of peers • Does somebody else GET to influence routing? • Some scenarios span administrative domains • Impeded access scenario explicitly votes “no” • Does somebody else HAVE to influence routing? • Support for ad hoc overlays, first responders, etc. • Please read (and savage) Applications Scenarios • draft-bryan-p2psip-app-scenarios-00.txt
Please start talking now… • How many routing techniques do we need, and can we pick a set? • Discuss/compare different routing techniques (iterative, recursive, semi-recursive, as well as symmetric vs. asymmetric). • Can we decide on a set for the protocol to implement?