IETF PPSP working group
Charter: http://datatracker.ietf.org/wg/ppsp/charter/
Chairs:
Martin Stiemerling <stiemerling@netlab.nec.de>
Yunfei Zhang <zhangyunfei@chinamobile.com>

Meeting minutes of the virtual interim meeting, held September 28th, 2011

The meeting was held via the Webex online meeting facility at
http://www.webex.com

Presented slides are temporally available here, until December 2011:
http://www.stiemerling.org/ietf/ppsp/20110928-ppsp-virtual-interim-slides.zip

Start time: 2:00pm CEST
End time:   4:20 pm CEST

** Final Agenda
* Agenda bashing
* Chair's introduction on PPSP progress
* Tracker Protocol and discussion
  current candidates:
  http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-tracker-protocol/
  http://datatracker.ietf.org/doc/draft-gu-ppsp-tracker-protocol/
* Peer protocol and discussion
  current candidates:
  http://datatracker.ietf.org/doc/draft-gu-ppsp-peer-protocol/
  http://datatracker.ietf.org/doc/draft-cruz-ppsp-http-peer-protocol/
  http://datatracker.ietf.org/doc/draft-grishchenko-ppsp-swift/
* Trails/Interop discussions
* Conclusion and next steps                                    


**Meeting Minutes
Note taker: Martin Stiemerling
NB: minutes in <> are added by the note taker or raise missing or unclear
parts.

The virtual interim meeting started at 2pm CEST. 

The co-chairs Yunfei Zhang [YZ] and Martin Stiemerling [MS] started the PPSP virtual
interim with the agenda bashing. 

Johan Pouwelse [JP] asked if the peer protocol slot can also include a short
intro about draft-grishchenko-ppsp-swift and if there is time to discuss future
PPSP trails.  

[MS] The peer protocol slot is for all peer protocols to be discussed and there
is time to disucss trials. 

[MS] Short review of the current status of the PPSP WG. 
[MS] When shall we start with the WGLC for the draft draft-ietf-ppsp-survey
before the next IETF meeting or after?
Yingjie Gu[YG] Prefer to have it after the IETF meeting.
[MS] Will do the WGLC for the  draft draft-ietf-ppsp-survey after the IETF#82
meeting and will use the time before the meeting to work on the protocols. 

* Tracker Protocol and discussion
[YG] presented the current status of draft-gu-ppsp-tracker-protocol.
[MS] Is draft-gu-ppsp-tracker-protocol already merged with
draft-cruz-ppsp-http-tracker-protocol?
[YG] No, not yet.
Arno Bakker [AB] HTTP is not bidirectional, server cannot send to client without receiving a request.
[YG] STAT_QUERY required for clients
Note: There was a longer discussion about if STAT_QUERY is needed and how it would be implemented. It was stated that the current HTTP spec does not support this mode of operation yet, but on the other hand, some p2p systems may need the semantics of STAT_QUERY. This needs to be discussed further on the list. 

Rui Cruz[RC] raised a question about the chunk availability on slide 5 of the
tracker slides (20110928-ppsp-virtual-interim-PPSP-Tracker-Protocol).
<note taker didn't get what [YG] answer some follow-ups were>
This lead to the discuss how smart a PPSP tracker should be or if a rather simple
tracker would be sufficient. 

[AB] why do you not need to learn about new peers? <in relationship to the FIND
message>
[YG] This is what KEEPALIVE is doing. 
[RC] Seconds [AB] and adds that the meaning of the message is changed. 

[MS] Question about whether the XML encoding has been corrected.
[YG] XML encoding was revised.

[AB] What is the role of the certificates in the messages? Why not using HTTPS?
[YG] <missed her answer> 
[RC] Wouldn't it reasonable to use authentication tokens?
<missed the discussion, but it was about in protocol certicifactes vs HTTPS>
[MS] Use HTTPS standard solution, otherwise hard to built and to get through
the standards process. 
Marc Stuart [MaSt] 2 sides discussed here: open tracker, or closed and over-
engineered tracker. Marc supports a more simple tracker protocol.
[MS] will continue this simple vs. smart tracker to the mailing list.

* Peer protocol and discussion
The discussion started about whether the media transport protocol should be
part of the peer protocol or not, as the charter states "The first task for
this WG will be to decide which signaling and media transfer protocols will be
used. The WG will consider existing protocols and, if needed, identify
potential extensions to these protocols." and "PPSP is not chartered to work on
media transmission protocols". However, it should be noted that this does not
rule out that the WG has to consider what the media transmission protocols are.

<note taker missed some follow-up discussions>

[MS] do you have an implementation of draft-gu-ppsp-peer-protocol?
[YG] used to have an experimental implementation, but not the same as the
one in draft-gu-ppsp-peer-protocol. 
[AB] What about the encoding of IP addresses? Right now only IPv4 addresses are
specified, IPv6 is missing. 
[YG] Should consider this, no time yet. 

[RC] What was the reason to change to a binary encoding? We use HTTP for
signaling and media transport. Goes towards DASH. 
[MS] HTTP is causing too much overhead.
[YZ] In HTTP there is a server, in p2p there is no client/sever mode. HTTP is
not suitable, i.e., different from DASH.
[RC] We have implemented it and it works well.
[JP] No reason for HTTP if you want efficiency. strongly in favor of binary.
HTTP can be used as fallback, but this seems to be outside of PPSP.
[MS] Need to take this the mailing list to discuss the details.
[JP] Gave an update about draft-grishchenko-ppsp-swift.
[MS] draft-grishchenko-ppsp-swift should be casted in more IETF style.
[AB] What is people's preference was, based on their own use cases in terms
of media transport, e.g., a RTP extension or raw UDP?
<note taker missed the points made by [JP] and [MaSt]. 

* Trails/Interop discussions
[JP] Proposed to have a show-case of the different existing p2p protocol
implementations (libswift, draft-cruz, etc) on IETF.ORG. 
[MS] not possible to make such a show case on IETF.ORG; would need another
server to host this. 
[RC] willing to join the show case

This needs to be further discussed in the WG.

* Conclusion and next steps 

[MS] wraped up the meeting. Need to move discussions to mailing list. Start or
continue work on tracker and peer proocol.
[MS] proposed to work on tracker and peer protocol and to make a decision on
which proposal should become WG item by the next IETF meeting in November 2011. 
[RC] is there consensus on the timing and is there space for proposals?
[MS] the door for the protocols is not closed yet.
[JP] question about the decision process on what will be the WG item.
[MS] rough consensus, not formal voting.

The virtual interim meeting ended at 4:20 pm CEST. 

** End of meeting minutes.