1. draft-ietf-p2psip-base-03
Cullen Jennings
Bruce Lowekamp
Eric Rescorla
Salman Baset
Henning Schulzrinne
July 28, 2009

2. Miscellaneous Changes
Modified discovery process to allow other mechanisms to obtain overlay configuration.
Can use an enrollment server without DNS SRV
Can be entirely out of band without an enrollment server
Added max_response_length to prevent unintended large responses for Requests.
July 28, 2009
draft-ietf-p2psip-base-03

3. Forwarding Header/Via Lists/Frags
List discussion on resolving fragmentation and reassembly (separated from congestion control/reliability for now)
Route log (and flags) removed
Forwarding header aligned
Via-list now variable format, supports
16-bit compressed id (recommended form)
Resource/Node-ID
opaque/extension types
Fragmentation more clearly specified, allows room in each fragment for via-list
July 28, 2009
draft-ietf-p2psip-base-03

4. Overlay Algorithm Updates
Numerous text changes. Thanks to Vidya for comments
Now specifies periodic stabilization with an option to do reactive
WG voted a year ago to study problem further, but without further results, this is a compromise
Separated handling of failure from stabilization
More details of finger table maintenance
July 28, 2009
draft-ietf-p2psip-base-03

5. draft-ietf-p2psip-base-03
Support for New Kinds
From list discussion (mostly suggestions from Vidya)
USER-KEY-MATCH access control model
NODE-KEY-MATCH access control model
Configuration file can specify NodeIDs allowed to sign new kinds
July 28, 2009
draft-ietf-p2psip-base-03

6. draft-ietf-p2psip-base-03
Clients in RELOAD Base
Clients in RELOAD are not first-class entities
No behavior is specific to clients
Peer does not differentiate between a client and a Peer Attached that have not send an Update
Added more text on client functionality in base.
Added requirement that all connected nodes be sent Update when responsible ID range changes.
Unfortunately, Update is overlay-algorithm specific
July 28, 2009
draft-ietf-p2psip-base-03

7. draft-ietf-p2psip-base-03
Client Update Options
Client pings to check responsible peer
Frequency checks an issue
Client sends RouteQuery when Update it doesn’t understand is received
Works with one extra request
New generic method sent to non-Updated connections that specifies changes in responsible and replica peers
New method, but also allows clients to maintain connections to replica responsible peers in case responsible peer fails.
July 28, 2009
draft-ietf-p2psip-base-03

8. Overlay Link Changes and Path Forward
Significant list discussion about congestion control and reliability. Have open issues and need a path forward
Main text of draft specifies stop-and-wait and a simple receiver
AIMD and TFRC moved to appendix
Not the right long-term solution, options for long-term solution:
ICE-TCP likely completion (and works better)
TCP over UDP likely completion
SCTP over UDP likely completion
Algorithm from another source
Current semi-reliable AIMD sender after vetting through TSV
Need to make a choice as we approach WGLC
July 28, 2009
draft-ietf-p2psip-base-03

9. Option Header for all Methods
Forwarding Header has ForwardingOptions to allow extensions to mandate routing behavior.
Future (and current) drafts may want same behavior for other methods.
Propose to add list of RequestOptions
TLV
DESTINATION_CRITICAL flag
Full proposal will be brought to list
July 28, 2009
draft-ietf-p2psip-base-03

10. draft-ietf-p2psip-base-03
*Attach* Issues
Added AppAttach* as previously agreed
Now have:
Attach
AppAttach
AttachLite
AppAttachLite
Also have a normative dependence on ICE-TCP, which is the only way to use TCP in an overlay with NATs.
ICE-TCP is “stalled”
July 28, 2009
draft-ietf-p2psip-base-03

11. draft-ietf-p2psip-base-03
*Attach Proposal
Possible solution for TCP is to allow TCP only when ICE is not needed.
This is roughly the same as *AttachLite
The reason for *Lite being separate was that they were for use on *Lite-only overlays.
Proposal: Remove *Lite methods by merging functionality into main methods. *Attach would then offer a top-level option to either do ICE or advertise addresses that are known to accept inbound connections.
Full proposal will be brought to list.
July 28, 2009
draft-ietf-p2psip-base-03

12. draft-ietf-p2psip-base-03
Revision Plans
Looking for high-level editorial feedback
Looking for open technical issues
Will release one revision focusing on each topic
September 18: technical update
October 9: pure editorial update
July 28, 2009
draft-ietf-p2psip-base-03