PPSP @ IETF 87

WG Chairs presented on status
- first RFC on problem statement was published
- peer protocol getting ready for IESG review

Arno Bakker presented on the peer protocol (PPSPP)
- discussed updates since IETF 85 (3 revisions)
- still addressing AD review points now

- reviewed basic set of messages (about 3 new people in room asked for this)

- Merkle hash trees are mandatory
- LEDBAT as congestion control
- no formal protocol message definition (to be added)
- removing implicit use of default values
- introduced concept of channels

- discussed live-streaming integrity protection

- much discussion about chuck size and MTU
  - no way to discover MTU
  - default chunk size intended not to cause fragmentation
  - Wes suggests looking at PLPMTUD - not sure it's necessary though
  - Michael T. suggests that there's per-peer state to track for this


Dave C. presented on implementation he's been doing
- BitTorrent didn't seem like what he needed for work with CouchDB
- talked about CouchDB replication using P2P - PPSP looks like a match
- implementing in Erlang/OTP - good for low-latency + cuncurrency
- parser code matches the spec really well
- Martin asked about whether LEDBAT is implemented?
  - answer - NO, doesn't feel it's needed here, doesn't use UDP, uses
    a native Erlang cluster protocol


Ning Z summarized the status on the PPSP survey draft
- asked about next steps
- already had a WGLC, substantial modifications, chairs would like to
  proceed with the AD review after a couple of weeks


Lingli D. gave presentation on the latest tracker protocol draft
- Arno commented that it's explained in person much better than in draft
- binary versus text encodings are still confusing (multiple comments Arno & Martin)
- fitting in a single TCP packet comment is confusing
- Arno - base protocol doesn't allow a refresh after initial exchange
  - BitTorrent allows new peer lists, PPSP base protocol should
  - peer can contact the tracker after registered, it is true that base protocol
    doesn't allow getting a fresh peer list, desire was to keep as simple as possible
  - Arno does not agree, and he was one of original proponents to simplify tracker
  - Martin supports what Arno said
  - Dave gave the same feedback
  - Stefano called consensus to put this back
 - Martin asked about HTTP/2.0 ... Rui had mentioned this ... agreement that it
   doesn't make sense


Rachel H. presented on extended tracker protocol
- discussed motivations
- Arno questions whether some functionalities should be included in any
  tracker protocol - switching connections / mobility is out of scope
- Dave asked about whether these issues are all special cases of a peer no
  longer being available
- overview of extended tracker protocol
  - enhancement of 2 messages + 2 optional messages
- Martin asked if there was a requirement that peer for FIND be a leecher
  - seeder does not have peer list information
  - will take this to list
  - Arno has specifically asked about this in the past
  - Rui on webex seems to agree to allow seeders to requiest peer list

 - Stefano asked if WG believes functions present in base & extended tracker
   protocols are okay?
   - Stefano thinks maybe it needs a little more work
   - Ning agrees with need to check current alignment of functions
   - Was ability to get peer list updates the only issue? is deeper review needed?
   - Ricardo P. thinks base protocol should just get peers (no register)
   - Arno is fine with base, given the addition of peer list refresh


Lingli D. discussed bloom fliter for chunk availability compression
- uncompressed bitmap can be several KB and frequently exchanged
- Ricardo does not think this is a problem : the peer protocol does not use bitmaps
- Arno suggests looking at average case and not worst case
- Lingli says worst case is relevant to operators
- Ricardo says it has to do with fragmentation and there's tendency to move too much
  responsibility to the tracker
- Lingli is focusing mainly on tracker ... but it has to communicate with peer
- problem is only applicable to partial caches with holes, not to full caches that
  would be seeders or cases where continuous ranges are cached
- Ricardo agrees transmission of bitmaps has been a problem
  - even though inefficient, it proved to work
  - in streaming you have contiguous range, and don't need to send entire bitmap
  - normally tracker communication is not as frequent as peer
  - only requirement should be for tracker to give list of peers
- Dave thinks someone somewhere is keeping state; it is expensive, need to make it
  clear where this is done and also if the window of interest is sliding along
  (like with video) there's less of an issue
- Stefano suggests to take this to the mailing list before deciding; discuss if
  there is data that can help in determining