Minutes for PPSP at IETF-interim-2011-ppsp-1

Meeting Minutes Peer to Peer Streaming Protocol (ppsp) WG
Title Minutes for PPSP at IETF-interim-2011-ppsp-1
State Active
Other versions plain text
Last updated 2011-10-07

Meeting Minutes

IETF PPSP working group
Charter: http://datatracker.ietf.org/wg/ppsp/charter/
Martin Stiemerling
Yunfei Zhang

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

The meeting was held via the Webex online meeting facility at

Presented slides are temporally available here, until December 2011:

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:
* Peer protocol and discussion
  current candidates:
* 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

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
[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).

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?
[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?
[RC] Wouldn't it reasonable to use authentication tokens?

[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.

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