80 likes | 89 Views
This draft document outlines the requirements for a peer protocol, including reliable message delivery, routing function, support for existing and new DHT algorithms, and NAT traversal. It also covers additional requirements such as security, availability, replication, and routing efficiency.
E N D
Requirements for Peer protocoldraft-jiang-p2psip-peer-protocol-requirement-00.txt Jiang XingFeng (Johnson) Jiang.x.f@huawei.com P2PSIP WG, IETF #68
Background • Lots of protocol proposals, some use cases, no agreed requirements • We need good requirements, so David Bryan suggested that we work on them • Previous draft-draft-baset-sipping-p2preq-00 (expired May 2006) • Authors: S. Baset, H. Schulzrinne, E. Shim, K. Dhara • This draft is mostly independent - some text reuse, with permission (thank you) • Will compare more carefully now that we met 00 deadline!
Basic requirements - 1 • Peer protocol should rely on a transport mechanism which would guarantee reliable message delivery • The ratio of payload to message size should be kept as high as possible • Peer protocol must provide a few primitive functions which are essential for most DHT algorithms • Join, Leave, Get, Put, Remove • Peer protocol should provide routing function in the overlay
Basic requirements - 2 • Peer protocol should provide redundant storage function in the overlay • Peer protocol should accommodate a few existing DHT algorithms and at the same time, be extensible enough to support new DHT algorithms in the future • Peer protocol should allow Peers to communicate with each other by traversing NAT device
UDP or TCP • UDP or TCP for Transport? • Hard to fit enough info in one MTU • But UDP good for NAT traversal, reduces load with more connections • Open issues • Compress headers, leave out some information • Binary or ASCII protocol? • Self-fragment/reassemble? • Is the TCP overhead worth it? • (DHTs maintain a lot of connections and frequently use short-lived connections)
Additional Requirements • Security requirements • Need certificates to authenticate all messages • Distributed mechanism to distribute/acquire certs • Resource registrations need to be authenticated by registering entity, not responsible peer
Advanced requirements • Availability • Neighbor detection • Some remedial actions could be taken after peer’s failure is detected • Replication • Peer protocol should place several replicas into the overlay and make the corresponding information available all the time • Routing efficiency • Cache mechanism • Hops which requests traversed are shorten and the lookup operations become more efficient