March P2PSIP Routing Discussion (“Routing: what does it look like?) Spencer Dawkins IETF 70 – December 2007 Vancouver, British Columbia

March 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?

March 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?

March 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

March 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!

March 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?

March 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

March 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?