Subject: [ppsp] Selection of PPSP peer protocol draft

From: Martin Stiemerling <[email-masked]>
Date: Thu, 24 Nov 2011 14:42:32 +0000

Dear all, 

The working group has to make a decision which peer protocol proposal to choose as basis for the PPSP peer protocol. 

We have to independent proposals:
- draft-gu-ppsp-peer-protocol-03
  (http://tools.ietf.org/html/draft-gu-ppsp-peer-protocol-03)
- draft-grishchenko-ppsp-swift-03
  (http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03)

Both proposals for a peer protocol have been presented at the IETF meeting. The slides are available here:
- draft-gu-ppsp-peer-protocol-03:
  http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx
- draft-grishchenko-ppsp-swift-03
  http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf

The feedback given at the IETF meeting about both proposals is documented in the draft meeting minutes:
http://www.ietf.org/proceedings/82/minutes/ppsp.txt

Please state your **technical** opinion about which peer protocol proposal you would prefer on the PPSP mailing list until November 30th.

With best regards

  Yunfei and Martin
     PPSP co-chairs

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: Arno Bakker <[email-masked]>
Date: Mon, 28 Nov 2011 11:17:50 +0100

>
> Please state your **technical** opinion about which peer protocol
> proposal you would prefer on the PPSP mailing list until November
> 30th.
>

Hi

I prefer the swift proposal to be the basis for the peer protocol,
obviously (if it is bad form to vote for you own proposal, I apologize).
The Gu+Cruz proposal, IMHO contains some poor design choices, and is at 
present incomplete and inmature. The poor design choices are the 
preference for a pull-based model, e.g. for chunk availability and the 
preference for HTTP as a transport.

As argued in the meeting, a pull-based model for getting the chunk 
availability of peers does not fit well with contemporary chunk 
selection policies. These policies commonly use rarest-first as an 
important element (VOD). Rarest-first is a simple way of ensuring that 
peers have chunks to upload to each other, so a simple way of ensuring 
the upload bandwidth of peers is exploited. For rarest-first, up-to-date 
information about chunk availability is needed, which is most easily 
achieved by pushing availability updates.

I haven't gotten an answer to my questions of how peers' upload capacity 
is exploited in the Gu+Cruz system (they don't seem to use 
rarest-first), and how they avoid high latencies (a risk because they 
pull info).

Furthermore, HTTP is not a good basis for a peer-to-peer protocol as it 
is asymmetric, leading to double TCP connections and NAT firewall 
complications, as well as a kludgy design. The other proposed encoding, 
dubbed binary, is inmature, making (inefficient) design choices without 
explanation and containing technical flaws (defining 8-bit encoding as 
7-bit ASCII).

The Gu+Cruz proposal is also incomplete. It hints at support for 
multiplexing of messages and piggybacking to reduce latency. But the 
specification is incomplete (some support in binary encoding, no in HTTP 
encoding) and broken (can only multiplex request or replies, not a mix).

Regards,
     Arno

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 00:17:42 +0000

Hi,

I am in favor of Swift as a Wire Format and Message Transport candidate for the PPSP Peer Protocol, although the Media Data Transport may need further discussions (Data Transport is not in the scope of the signaling protocol, although the design may determine it).

However…

I would reconsider if the situation is for either one or the other draft to be voted as preferred in the WG. 

Opinions have balanced from a "merger, as both have some advantages", "some features can be included into the other proposal", "take swift as basis" or "'extensions' can be added, that parse the data (or the metadata) to get infos needed by download algorithms" because "information about the distortion, the interdependency between chunks (to reflect coding dependencies), the temporal vs. spatial scalability/layering to be conveyed" may be needed for the scheduling algorithms.

Neither of the drafts presented a complete protocol architecture. 

And so, I would propose the following alternatives (not in andy preferred order) to the simple white/black voting:

Alternative 1: one draft would proceed describing the Protocol Architecture, Semantics, Syntax and Logic, and the other draft the way to implement the Wire Format/Encoding layer and Message Transport layer, suggesting and justifying Network Transport preferences.
Alternative 2:  "merging the efforts", not the "proposals" on defining the Protocol Architecture, Semantics and Logic and refining the Wire Format/encoding and Message Transport layers, in an orchestrated way. Both teams could perfectly do their best to converge into a complete specification. 

The reasons behind this proposal are the following, for which some responses and comments would enrich the discussion in the Mailing List:

1. Architecture
The PPSP Peer Protocol design needs a very clear Architecture in order to address Semantics, Syntax, Operation Logic and "services" provided, as the "Peer Agent" interfaces and interacts with a Client Media Player (in order to stream what the User requests, even if the User is playing Tricks, like jumping forward in the movie or selecting a different audio dubbing or subtitle language). 
 
The Architecture would describe, at least: 
- Peer Selection criteria: based of location, capabilities, etc., 
- Streaming Modes support: live, on-demand, and how to obtain, ahead of data, updates for the chunk IDs of the live media sliding window, 
- Extensibility: in terms of the support/cooperation with diverse media representations and media structures/encodings, as the "Peer Agent" should not take decisions on interdependency between media chunks or representations (coding dependencies) of Structured Media, and that role should be performed at the Media Player application level. However it should cooperate for the correct and adequate download scheduling of the required (externally ordered) media chunks (where chunks correspond to segments of media, with similar duration, divided at points that support effective individual decoding, e.g., on packet and key frame boundaries).
- Interactions with: the Client Application (and Media Player) and support of media Trick-Function requests, the Tracker(s) 
- Operation Semantics: the "Peer Agent" is NOT the Media Player, therefore does not take decisions on what to watch (presentation) or at which media presentation time to start watching, at any moment.

2. Wire Protocol
The Wire Protocol goal is to provide the adequate framework (not concerned with implementation and semantics of operation) for the invocation of operations on resources, considering:
- "service-side" interface: with the Client Application, with the Tracker processes components (in the Peer).
- "transport-side" interface: object types/assets, methods/messages, requests/replies/results operations, error codes/conditions either explicit or implicit, integrity, addressing.

3. Message Transport
The Message Transport addresses the efficient delivery of messages, independently of their meaning or purpose:
- message segmentation (message boundaries)
- multiplexing, pipelining, channeling
- flow and congestion control 

From what is written in the swift description draft, there is no interaction with the Media Player apart from feeding it with the downloaded media, meaning that, as soon as the "Peer" knows the root Hash or Public key (Swarm-ID) immediately starts pulling all the media to feed the Player, without any interaction. The method is, apparently, similar to a multi-source "progressive download".
One important aspect is that the signaling for bitmaps/hashes of swift is push-mode, but the Media DATA streaming is always PULL-Mode, for either Live or on-demand.  

About the support of Structured Media, I could not see evidence of that, nor how Swift deals with several representations of the media, i.e., video (several clips, multiple bitrates, layers), audio (different audio dubbing languages), text (different subtitle languages), unless all are multiplexed in a container file, or "contained" in a directory of files, in order to be hashed in byte ranges. 
An example of such a structure is the following, for a 10 seconds video encoded in SVC with two spacial resolutions (432x240 and 842x480) and 6 layers for quality fidelity, with an associated Audio track. Each segment (with chunks labelled .00, .01, .02, etc for the different layers) corresponds to a duration of 2 seconds of media playout, and the corresponding sizes are also indicated (example taken from a real test video).

For this example, I suppose that swift would have to hash independently each chunk, am I right? But then, how would it address the scalability, as the Client Player requester, would eventually not request all the layers of a segment during those 10 seconds of duration (perhaps, starting only up to layer L3 on the first segment, then raising to L4, then L5 in the following segments, or, if bandwidth would allow up to L6 for the remaining segments).

+++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER CHUNKS 
162 KiB     172 KiB     154 KiB     157 KiB     177 KiB 

+++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER CHUNKS 
117 KiB     121 KiB     113 KiB     120 KiB     117 KiB 

+++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER CHUNKS
4 KiB       6 KiB       6 KiB       6 KiB       4 KiB 

+++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER CHUNKS
3 KiB       5 KiB       5 KiB       6 KiB       4 KiB 

+++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER CHUNKS
5 KiB       6 KiB       5 KiB       6 KiB       6 KiB 

+++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER CHUNKS
54 KiB      55 KiB      49 KiB      53 KiB      58 KiB 

+++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER CHUNKS
50 KiB      52 KiB      50 KiB      53 KiB      50 KiB   

+++AA.00+++ +++AA.01+++ +++AA.02+++ +++AA.03+++ +++AA.O4+++ AUDIO Chunks
5 KiB       5 KiB        5 KiB        5 KiB        5 KiB  

---------------------------
Best Regards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
[email-masked] 
[email-masked]
[email-masked]
www.ieee-pt.org
Advancing technology for humanity.

On 24/11/2011, at 14:42, Martin Stiemerling wrote:

> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Ye Wang" <[email-masked]>
Date: Tue, 29 Nov 2011 01:12:47 -0500

Hi Rui,

I think you are making a very important point.

The protocol(s) to be standardized should carefully define what system
architecture it fits in, what media types it can handle, what interfaces it
can provide to streaming consumers (such as media player), etc.

Specified protocols can be a great solution to some specific system designs,
but the WG may still need a more general standard.

For example, we encounter a similar problem as what Rui mentioned, when we
need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, 480p,
720p HD).  We need to customize our protocols to make our system working
more efficiently: in particular we decide to map different video chunks
(from different sources, with different sizes) to the same id, based on
corresponding video frame timestamp.

Another example is regarding the debate on the push/pull of the bitmap.
When our system works with low-capacity video source (e.g., a single server)
and small chunk size, we build an overlay network with multi-hop diameter,
and it turns out the push scheme performs better as it is an efficient way
for the peers to discover the newest/rarest chunks in the channel, even
though it consumes around 10% of the peer upload capacity; but when we have
large-capacity source (e.g., a set of CDN access points) and large chunk
size (e.g., to accommodate HTTP overhead when working with CDN), the pull
based scheme actually saves peer uplink resource, since the overlay
structure is not “deep”, so each peer just need to request neighbors about
their chunk availability “on demand” (as long as their neighbor’s capacity
is already efficiently utilized) because it can always fetch from source if
it is not happy about the progress.

Thanks,

Ye

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui
Cruz
Sent: Monday, November 28, 2011 7:18 PM
To: [email-masked]
Cc: Rui Cruz
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi,

I am in favor of Swift as a Wire Format and Message Transport candidate for
the PPSP Peer Protocol, although the Media Data Transport may need further
discussions (Data Transport is not in the scope of the signaling protocol,
although the design may determine it).

However…

I would reconsider if the situation is for either one or the other draft to
be voted as preferred in the WG. 

Opinions have balanced from a "merger, as both have some advantages", "some
features can be included into the other proposal", "take swift as basis" or
"'extensions' can be added, that parse the data (or the metadata) to get
infos needed by download algorithms" because "information about the
distortion, the interdependency between chunks (to reflect coding
dependencies), the temporal vs. spatial scalability/layering to be conveyed"
may be needed for the scheduling algorithms.

And so, I would propose the following alternatives (not in andy preferred
order) to the simple white/black voting:

Alternative 1: one draft would proceed describing the Protocol Architecture,
Semantics, Syntax and Logic, and the other draft the way to implement the
Wire Format/Encoding layer and Message Transport layer, suggesting and
justifying Network Transport preferences.

Alternative 2:  "merging the efforts", not the "proposals" on defining the
Protocol Architecture, Semantics and Logic and refining the Wire
Format/encoding and Message Transport layers, in an orchestrated way. Both
teams could perfectly do their best to converge into a complete
specification. 

The reasons behind this proposal are the following, for which some responses
and comments would enrich the discussion in the Mailing List:

1. Architecture

The PPSP Peer Protocol design needs a very clear Architecture in order to
address Semantics, Syntax, Operation Logic and "services" provided, as the
"Peer Agent" interfaces and interacts with a Client Media Player (in order
to stream what the User requests, even if the User is playing Tricks, like
jumping forward in the movie or selecting a different audio dubbing or
subtitle language). 

- Streaming Modes support: live, on-demand, and how to obtain, ahead of
data, updates for the chunk IDs of the live media sliding window, 

- Extensibility: in terms of the support/cooperation with diverse media
representations and media structures/encodings, as the "Peer Agent" should
not take decisions on interdependency between media chunks or
representations (coding dependencies) of Structured Media, and that role
should be performed at the Media Player application level. However it should
cooperate for the correct and adequate download scheduling of the required
(externally ordered) media chunks (where chunks correspond to segments of
media, with similar duration, divided at points that support effective
individual decoding, e.g., on packet and key frame boundaries).

- Interactions with: the Client Application (and Media Player) and support
of media Trick-Function requests, the Tracker(s) 

- Operation Semantics: the "Peer Agent" is NOT the Media Player, therefore
does not take decisions on what to watch (presentation) or at which media
presentation time to start watching, at any moment.

2. Wire Protocol

The Wire Protocol goal is to provide the adequate framework (not concerned
with implementation and semantics of operation) for the invocation of
operations on resources, considering:

- "service-side" interface: with the Client Application, with the Tracker
processes components (in the Peer).

- "transport-side" interface: object types/assets, methods/messages,
requests/replies/results operations, error codes/conditions either explicit
or implicit, integrity, addressing.

3. Message Transport

The Message Transport addresses the efficient delivery of messages,
independently of their meaning or purpose:

>From what is written in the swift description draft, there is no interaction
with the Media Player apart from feeding it with the downloaded media,
meaning that, as soon as the "Peer" knows the root Hash or Public key
(Swarm-ID) immediately starts pulling all the media to feed the Player,
without any interaction. The method is, apparently, similar to a
multi-source "progressive download".

One important aspect is that the signaling for bitmaps/hashes of swift is
push-mode, but the Media DATA streaming is always PULL-Mode, for either Live
or on-demand.  

About the support of Structured Media, I could not see evidence of that, nor
how Swift deals with several representations of the media, i.e., video
(several clips, multiple bitrates, layers), audio (different audio dubbing
languages), text (different subtitle languages), unless all are multiplexed
in a container file, or "contained" in a directory of files, in order to be
hashed in byte ranges. 

An example of such a structure is the following, for a 10 seconds video
encoded in SVC with two spacial resolutions (432x240 and 842x480) and 6
layers for quality fidelity, with an associated Audio track. Each segment
(with chunks labelled .00, .01, .02, etc for the different layers)
corresponds to a duration of 2 seconds of media playout, and the
corresponding sizes are also indicated (example taken from a real test
video).

For this example, I suppose that swift would have to hash independently each
chunk, am I right? But then, how would it address the scalability, as the
Client Player requester, would eventually not request all the layers of a
segment during those 10 seconds of duration (perhaps, starting only up to
layer L3 on the first segment, then raising to L4, then L5 in the following
segments, or, if bandwidth would allow up to L6 for the remaining segments).

+++L6.00+++ +++L6.01+++ +++L6.02+++ +++L6.03+++ +++L6.O4+++ ENH6 LAYER
CHUNKS 

+++L5.00+++ +++L5.01+++ +++L5.02+++ +++L5.03+++ +++L5.O4+++ ENH5 LAYER
CHUNKS 

+++L4.00+++ +++L4.01+++ +++L4.02+++ +++L4.03+++ +++L4.O4+++ ENH4 LAYER
CHUNKS

+++L3.00+++ +++L3.01+++ +++L3.02+++ +++L3.03+++ +++L3.O4+++ ENH3 LAYER
CHUNKS

+++L2.00+++ +++L2.01+++ +++L2.02+++ +++L2.03+++ +++L2.O4+++ ENH2 LAYER
CHUNKS

+++L1.00+++ +++L1.01+++ +++L1.02+++ +++L1.03+++ +++L1.O4+++ ENH1 LAYER
CHUNKS

+++L0.00+++ +++L0.01+++ +++L0.02+++ +++L0.03+++ +++L0.O4+++ BASE LAYER
CHUNKS

Best Regards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto
Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
[email-masked] <x-msg://127/[email-masked]>  
[email-masked] <x-msg://127/[email-masked]> 
[email-masked] <x-msg://127/[email-masked]> 
www.ieee-pt.org <http://www.ieee-pt.org/> 
Advancing technology for humanity.

Dear all, 

The working group has to make a decision which peer protocol proposal to
choose as basis for the PPSP peer protocol. 

Both proposals for a peer protocol have been presented at the IETF meeting.
The slides are available here:
- draft-gu-ppsp-peer-protocol-03:
 http://www.ietf.org/proceedings/82/slides/ppsp-3.pptx
- draft-grishchenko-ppsp-swift-03
 http://www.ietf.org/proceedings/82/slides/ppsp-1.pdf

The feedback given at the IETF meeting about both proposals is documented in
the draft meeting minutes:
http://www.ietf.org/proceedings/82/minutes/ppsp.txt

Please state your **technical** opinion about which peer protocol proposal
you would prefer on the PPSP mailing list until November 30th.

With best regards

 Yunfei and Martin
    PPSP co-chairs

NEC Laboratories Europe - Network Research Division NEC Europe Limited |
Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in
England 2832014

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 29 Nov 2011 02:13:23 -0500

Hi all,

I read both specs, and the meeting minutes but missed this IETF at 
Taipei. So if I am repeating some discussions already happened, please 
let me know.

First off, I got the feeling that multiple votes for swift over 
draft-gu-ppsp-peer were based on maturity, at this moment.  I think this 
is not a good idea, as maturity can change in a relatively short time 
period, say between two IETFs, through some intensive engineering 
efforts, and we are designing a protocol that will last a much longer 
period. Hence it is important to consider the key technical design. I 
would personally prefer an HTTP based protocol, if we can show that it 
works, as HTTP is really the thin waist of the Internet now. It will be 
great if the authors of draft-gu-ppsp-peer would like to make their 
protocol complete, addressing the key concerns, for example, 
bi-directional HTTP communications, say using websocket, so that we can 
make a more informed decision. People mostly watch video using browsers. 
We should consider more browser-native protocols, if possible, for ppsp 
design.

Since the swift protocol is more completely specified at this moment, 
let me comment more on this protocol. The swift protocol is a quite 
interesting protocol. I feel  that using UDP as transport is one 
potential path, as Adobe P2P is based on UDP as well. My main comments 
on swift are the following:

* Are there any experimental results of swift at large scale real 
experiments?

* According to our experiences at building an experimental p2p streaming 
system at Yale, a real protocol quickly becomes complex as we continue 
to extend it to handle challenges in real settings. The extension scheme 
of the protocol needs careful thinking.

* So far the draft contains many policies. I have not been convinced 
that they are necessary. For example,

    - page 4 top: "... peer connects to a random set of other peers ..." 
why random?

    - page 4 "... omits HAVE messages as a way of choking A."

       Also Page 7 on withholding HAVE. Also on Page 7 on withholding 
error messages.

       I typically do not like such information-hiding designs. Informed 
decisions often are better, faster decisions.

    - page 4 (also page 9) "... A sends a datagram containing HAVE 
messages for the chunks it just received to all its peers." Specifying 
such a push-just-received model may not be necessary.

    - The design is essentially pushing for an uploader centric design. 
This is unnecessary.

    - The idea of using a tree to introduce bins and compute hashes is 
interesting. Two comments:

       - I am wondering is the scheme is patented. CK Wong and Simon Lam 
presented such a design in 1998 (for disclosure, Simon Lam is my PhD 
advisor): 
http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf

          I am not sure if there is a patent on it. And if so, will it 
have impacts on the selection?

       - On the other hand, I am wondering if using such a binary tree 
based design is necessary, as elaborated schemes typically can have 
limit extensibility, compared with simple straightforward schemes . In 
particular, how much savings are we talking about, at the cost of 
choosing a particular binary tree based representation scheme? Such 
information can be helpful.

To summarize, my vote is the following:

- Give the draft-ppsp-gu-peer authors some time (chance) to give a more 
mature design, if the authors are willing, before we make a decision.

- If swift is used, check the patent issue; optional, show some real 
experimental performance results; think about modular design (for 
example, more elaborate NAT/mobility handling handshake); make the 
protocol more policy neutral (e.g., by involving algorithmic designers 
to leave enough design space); make sure it is extensible in the message 
flows.

Just some quick comments as input.

Thanks!

Richard

---

From: Njaal Borch <[email-masked]>
Date: Tue, 29 Nov 2011 11:56:55 +0100

Hi, I work at the Northern Research Institute, where I have been
working on design and development of P2P systems for a number of
years.  I have a PhD within P2P networks, designing and creating a
fully decentralized social P2P network (the "Socialized.net",
2003-2007).  I have later worked with a variety of protocols,
including modifications to BitTorrent and some recent work on swift.

My vote goes to the swift proposal.  I find the design promising, as
it is relatively concrete, rather easily implemented and covers the
current fundamental issues of P2P networks (e.g. NAT traversal,
efficient two-way communication, data integrity etc).  It is also open
for extensions and optimization as network characteristics and usage
patterns evolve.  As examples, the hash tree can allow requests/hash
checks on larger chunks for larger connections, flow control can be
adapted for the client's need and swift opens for a large variety in
incentives.  Incentives are very important in P2P networks, and while
swift doesn't in itself address this directly, it is a design very
open for addressing this through resource investments and so forth.

The swift proposal is not only more mature, it is a proposal which is
based on several years of experimental research carried out by lead
researchers within P2P, in particular within P2P video streaming. It
provides a rather elegant solution to actual real-world issues
currently hindering P2P efficiency (specially NAT and asymmetric
network connections).  The simplicity of the protocol allows for a
great deal of improvements on policies, which do not affect the wire
protocol itself. This can again open for a protocol which can be
adapted to the specific task at hand by the clients.  I see it as a
great benefit that the protocol does not try to be too generic or too
adaptable at the lower level, as it makes implementations more
difficult and makes it difficult for programmers and users to know
what to expect from the system.  It also opens for a time consuming
de-facto standardization of what is actually usable and supported by
different implementations.

In my opinion, swift carries a lot of potential as a protocol for the
next decade.  It is rather easy to implement, it is flexible and it
has already been shown to run on anything from large PCs to smart
phones and low-power systems.
Just looking at the discussions on the ppsp mailinglist, those based
on the swift proposal are already interesting discussions about piece
picking and other advanced technical challenges, while the other
proposal(s) have seen basic discussions on how many connections too
much is needed between each node pair (as one is the optimal), lacking
basic functionality and so fort.  Our time is best spent solving
actual problems, of which there are plenty, not by creating new ones.

Best regards,
Dr. Njål Borch
Northern Research Institute (Norut)
Tromsø, Norway

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 12:28:11 +0000

Hi Ye,

I fully agree with you.

And if the key technical design of the protocol architecture benefits from accumulated experience (from implementations) while not restricting the capabilities or extensibility, then a standard that will last for a longer period can be achieved.

Our group (EU Project SARACEN) is developing, and already has working prototypes (including handheld devices, currently over Android OS), of P2P Streaming distribution that supports adaptive dynamic streaming of Structured Media (SVC views, MVC/3D views) as well as multi-rate media representation switching, aimed to be compatible with CDNs and capable of on-demand or Live streaming modes, with interactive functionality (with the streaming consumer, e.g., media player) and Trick-Modes. The current restrictions (not in the P2P distribution process) are related with real-time encoding of Structured Media for Live streaming (namely SVC and MVC/3D). But having a pre-encoded media, it can be prepared in real-time for a Live streaming distribution. The structure of the encoded media is identical for live or on-demand modes, and only the method of distribution differs from a full content description mapping (for on-demand) to a latest generated programme sliding-window description mapping (for live, with the sliding window describing the latest N chunks, e.g., a 10 seconds window if N=5 and chunk duration is 2 seconds). 

And your point on bitmaps push/pull is precisely one of the issues we are also facing in terms of optimization as it may depend on the streaming mode and on the distribution network topology (source assisted, cached, or not, etc.) and the end node access link asymmetry. A gossip type push of bitmaps with a high frequency although representing a significant upload bandwidth slice may turn the scheme more efficient in low-capacity systems, but in case of large chunk sizes (a few seconds of media duration) an on-demand pull of chunkmaps, with a relatively low update frequency (not far from the chunk duration) typically does not represent a significant bandwidth consumption.

Thanks,
Rui

-----------------------------------
Best Regards,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Vice-Chair
IEEE Computer Society Portugal Chapter
[email-masked] 
[email-masked] 

On 29/11/2011, at 06:12, Ye Wang wrote:

> The protocol(s) to be standardized should carefully define what system architecture it fits in, what media types it can handle, what interfaces it can provide to streaming consumers (such as media player), etc.
> Specified protocols can be a great solution to some specific system designs, but the WG may still need a more general standard.
>  
> For example, we encounter a similar problem as what Rui mentioned, when we need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, 480p, 720p HD).  We need to customize our protocols to make our system working more efficiently: in particular we decide to map different video chunks (from different sources, with different sizes) to the same id, based on corresponding video frame timestamp.
> Another example is regarding the debate on the push/pull of the bitmap.  When our system works with low-capacity video source (e.g., a single server) and small chunk size, we build an overlay network with multi-hop diameter, and it turns out the push scheme performs better as it is an efficient way for the peers to discover the newest/rarest chunks in the channel, even though it consumes around 10% of the peer upload capacity; but when we have large-capacity source (e.g., a set of CDN access points) and large chunk size (e.g., to accommodate HTTP overhead when working with CDN), the pull based scheme actually saves peer uplink resource, since the overlay structure is not “deep”, so each peer just need to request neighbors about their chunk availability “on demand” (as long as their neighbor’s capacity is already efficiently utilized) because it can always fetch from source if it is not happy about the progress.
>  
> Thanks,
> Ye
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Cruz

---

From: "Yingjie Gu(yingjie)" <[email-masked]>
Date: Tue, 29 Nov 2011 20:58:29 +0800

I would like to recall the history of peer protocol. 
We began to propose Tracker and Peer protocol at early 2010. Since the very beginning, we believe that Peer protocol should be consistent with Tracker Protocol. By consistence, I don't mean that they can co-exist, instead they should share the similar philosophy and should be able to interoperate.  That's why we call them a system, not two single protocols.

PPSP had spent a lot of time on discussion on whether the PPSP standards should use Tracker-based or Full-mesh architecture (finally, WG got consensus on tracker-based), and how the Tracker and Peer protocol should work, which is in the Requirements draft. We always regards the requirements draft as a guidance on Tracker and peer protocol. Based on the requirements draft, we proposed draft-gu-ppsp-tracker-protocol and peer-protocol. 

The WG has spent a lot of effort on PPSP Survey, because we want to extract common features on current PPSP system, instead of base on a single private protocol. 

I agree that Swift works, and it is a research project supported by many research groups, and I think those show support for swift are mostly involved in SWIFT project. 
It will be easier for PPSP to get to an RFC published if we defining a protocol based on a mature private protocol. But what about other private protocols? ANY ONE of the protocols introduced in Survey draft can work well and most of them have much huge number of users than SWIFT, and even much better performance. Shall we take them into consideration?

I hate to make this selection as an attack on each other draft. And I hope those from SWIFT won't look at my email as an attack to their protocols. I just wonder what does PPSP WG want, a mature private protocol or a developing protocols based on widely survey? 

I agree with Cruz's opinion. This is not a selection of draft, we have more than one option. 

Best Regards
Gu Yingjie

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 13:26:19 +0000

Hi Richard,

It is very interesting your point on a Web-based P2P Streaming protocol. 

Bi-directional communications via Websocket is in fact the next step in a design (draft-cruz-ppsp-http-peer-protocol) for the Messaging Transport layer, together with a Wire Representation of messages, compatible with HTTP methods, that our group (EU SARACEN project) is developing.
And we already have working prototypes for the P2P Web Streaming Distribution, supporting Live and on-demand Structured Media Streaming (SVC, MVC/3D, etc.), using a Client Media Player Application (with special modules for the requester/re-assember of structured media, and corresponding decoders), or currently as a Firefox Plug-in, but evolving for a compatible HTML5 mechanism. 

As co-author of draft-gu-ppsp-peer-protocol, I would also be very happy to complete the key technical design of the PPSP Peer Protocol Architecture, but in a very open approach, not biased for the possible wire encoding and message transport formats and methods. 

Swift is in fact interesting, but, in my opinion, should be addressed as one of the Wire binary formats, currently the more mature. 

However, I am still not yet convinced that swift can handle (and provide interaction) with complex Structured Media, for example, allowing the end User to switch between audio (dubbed languages or "Director Commented") streams of a movie or switching between subtile languages, or cooperate in the adaptation or scalability of the media (multi layer, multi-rate switching).
And if the encoded complex structured media is segmented in rather large sized chunks (of 10x or 100x KiB) each chunk would have to be mapped, I suppose, to a quite large Hash tree to split the data in byte ranges for the datagrams. So, instead a a single Bin tree, a complex Structured Media with a duration of an hour (3600 seconds) would require at least 18000 Root hashes for chunks with 2 seconds encoded in 10 layers.  Would this not be overkill?

But a Web-based Wire format, can be another option, if, as you say, "we can show that it works". 

And we (in the SARACEN project) can show that it works. 

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Vice-Chair

On 29/11/2011, at 07:13, Y. Richard Yang wrote:

> Hi all,
> 
> I read both specs, and the meeting minutes but missed this IETF at Taipei. So if I am repeating some discussions already happened, please let me know.
> 
> First off, I got the feeling that multiple votes for swift over draft-gu-ppsp-peer were based on maturity, at this moment.  I think this is not a good idea, as maturity can change in a relatively short time period, say between two IETFs, through some intensive engineering efforts, and we are designing a protocol that will last a much longer period. Hence it is important to consider the key technical design. I would personally prefer an HTTP based protocol, if we can show that it works, as HTTP is really the thin waist of the Internet now. It will be great if the authors of draft-gu-ppsp-peer would like to make their protocol complete, addressing the key concerns, for example, bi-directional HTTP communications, say using websocket, so that we can make a more informed decision. People mostly watch video using browsers. We should consider more browser-native protocols, if possible, for ppsp design.
> 
> Since the swift protocol is more completely specified at this moment, let me comment more on this protocol. The swift protocol is a quite interesting protocol. I feel  that using UDP as transport is one potential path, as Adobe P2P is based on UDP as well. My main comments on swift are the following:
> 
> * Are there any experimental results of swift at large scale real experiments?
> 
> * According to our experiences at building an experimental p2p streaming system at Yale, a real protocol quickly becomes complex as we continue to extend it to handle challenges in real settings. The extension scheme of the protocol needs careful thinking.
> 
> * So far the draft contains many policies. I have not been convinced that they are necessary. For example,
> 
>   - page 4 top: "... peer connects to a random set of other peers ..." why random?
> 
>      Also Page 7 on withholding HAVE. Also on Page 7 on withholding error messages.
> 
>      I typically do not like such information-hiding designs. Informed decisions often are better, faster decisions.
> 
>   - page 4 (also page 9) "... A sends a datagram containing HAVE messages for the chunks it just received to all its peers." Specifying such a push-just-received model may not be necessary.
> 
>   - The design is essentially pushing for an uploader centric design. This is unnecessary.
> 
>   - The idea of using a tree to introduce bins and compute hashes is interesting. Two comments:
> 
>      - I am wondering is the scheme is patented. CK Wong and Simon Lam presented such a design in 1998 (for disclosure, Simon Lam is my PhD advisor): http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf
> 
>         I am not sure if there is a patent on it. And if so, will it have impacts on the selection?
> 
>      - On the other hand, I am wondering if using such a binary tree based design is necessary, as elaborated schemes typically can have limit extensibility, compared with simple straightforward schemes . In particular, how much savings are we talking about, at the cost of choosing a particular binary tree based representation scheme? Such information can be helpful.
> 
> - Give the draft-ppsp-gu-peer authors some time (chance) to give a more mature design, if the authors are willing, before we make a decision.
> 
> - If swift is used, check the patent issue; optional, show some real experimental performance results; think about modular design (for example, more elaborate NAT/mobility handling handshake); make the protocol more policy neutral (e.g., by involving algorithmic designers to leave enough design space); make sure it is extensible in the message flows.
>

---

From: "Y. R. Yang" <[email-masked]>
Date: Tue, 29 Nov 2011 09:08:12 -0500

> I hate to make this selection as an attack on each other draft. And I hope those from SWIFT won't look at my email as an attack to their protocols. I just wonder what does PPSP WG want, a mature pr…

I would like to second Yingjie's question. It is important to discuss the objective first. There are indeed other options, e.g., based on reverse engineering, ppsp could use as a base one of those extremely widely deployed (with tens of millions of real users) protocols, as long as there is no IP issue.

Protocol design is not an optimization problem, i.e., pick the optimal protocol. So what is the goal of ppsp? If time is the essence and the goal is to have a peer protocol coming out of IETF quickly, then swift can be a starting base. Tanenbaum talked about the timing of standardization based on a camel shape. I feel that p2p streaming is already at the lower half of the body, i.e., many commercial protocols already exist. I am wondering on the opinions of the chairs and other seasoned IETFs on an approach that PPSP could take, to make a difference. I understand that many want to discuss the specific technical details, but then I see endless debates.

Thanks!

Richard

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 29 Nov 2011 15:29:48 +0100

On 11/29/11 8:13 AM, Y. Richard Yang wrote:
> draft-gu-ppsp-peer were based on maturity, at this moment.  I think
> this is not a good idea, as maturity can change in a relatively short
> time period, say between two IETFs, through some intensive
> engineering efforts, and we are designing a protocol that will last a
> much longer period. Hence it is important to consider the key
> technical design. I would personally prefer an HTTP based protocol,
> if we can show that it works, as HTTP is really the thin waist of the
> Internet now. It will be great if the authors of draft-gu-ppsp-peer
> would like to make their protocol complete, addressing the key
> concerns, for example, bi-directional HTTP communications, say using
> websocket, so that we can make a more informed decision. People
> mostly watch video using browsers. We should consider more
> browser-native protocols, if possible, for ppsp design.

To restate what I argued during the meeting, I would wholeheartedly
discourage the idea of using HTTP as the transport for any peer-to-peer
protocol. Considerations about overhead, encoding and bi-directionality
aside, I just cannot see how people think they can make peers behind
different NATs reach each other, without some sort of relay -- no, uPnP
doesn't work with multiple levels of NAT, and yes, it'll be more quite
soon, but that's a very common case already. Least on standard ports
80/443, which are the actual thin waist of the (client/server) Internet.

-- 
Ciao,
Enrico

---

From: George Milescu <[email-masked]>
Date: Tue, 29 Nov 2011 16:54:19 +0200

> Please state your **technical** opinion about which peer protocol proposal you would prefer on the PPSP mailing list until November 30th.

Hello all.

I represent University POLITEHNICA of Bucharest, the largest technical
university in Romania. For the past few years we developed a research
group studying P2P protocols. We focused on congestion problems,
overlay enhancements, wire-protocol analysis.

Our vote goes to the Swift proposal [1] for the following reasons:

* Swift has a simple, elegant design. Complicated designs (like the
one proposed by Cruz+Gu) are very likely to cause problems in the long
term.

* Cruz+Gu uses HTTP as a P2P protocol basis. This requires a double
amount of connections to be created between peers and introduces a
potential asymmetry in the design. Increasing the number of
connections also creates problems regarding NAT traversal. Having the
nodes run HTTP servers does not allow the creation of lightweight
clients.

* The Swift implementation was proven to work in various scenarios,
both on mobile devices and STBs.

* The Cruz+Gu lacks clarifications about multiplexing of data streams
(in the current proposal the requests and replies can not be
multiplexed simultaneously).

[1] http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03

Best regards,
George

-- 
George Milescu
Teaching Assistant
University POLITEHNICA of Bucharest

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 14:56:03 +0000

[speaking as individual contributor and not as chair of the PPSP WG]

Hi there,

Replying to the proposal of the 2 alternatives:
Alternative 1:
I do not see how this will make a good protocol specification at the end. There must be one draft that contains everything so that an implementer can make a program out of this (or part of a program). This requires that semantics and syntax are in the same draft for the protocol. Furthermore, there is no space for an architecture, as we do protocols. There can be considerations how the protocol would interact with the rest of the program, i.e., the actual media player. But this is not part of the protocol specification.

Alternative 2:
I do not see the common ground of the 2 proposals that would allow a merger. As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial details for specifying a peer protocol for PPSP.
draft-grishchenko-ppsp-swift has much more technical meat in specifying the basis of a PPSP peer protocol, though there are also some rough corners.

I'm in clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer protocol. The protocol specification defines semantics and syntax. The defined semantics and syntax are what I understand and would be able to start working on an early implementation, though there is the need to get more things nailed down. But a proposal must not be perfect at this point of time.

The WG should consider elements of draft-gu-ppsp-peer-protocol as further input to the peer protocol.

  Martin

[email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Cruz
Sent: Tuesday, November 29, 2011 1:18 AM
To: [email-masked]
Cc: Rui Cruz
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi,

However...

1. Architecture

2. Wire Protocol

3. Message Transport

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Av. Prof. Dr. Aníbal Cavaco Silva, IST-TagusPark, Office 1-5, 2744-016 Porto Salvo, Portugal
+351 214 233 200 (ext 5044), +351.939 060 939 (mobile)
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>
www.ieee-pt.org<http://www.ieee-pt.org/>
Advancing technology for humanity.

Dear all,

With best regards

 Yunfei and Martin
    PPSP co-chairs

[email-masked]<mailto:[email-masked]>

_______________________________________________
ppsp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ppsp

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 14:58:14 +0000

Hi,

The PPSP protocols should fit a wide range of peer-to-peer TV architectures and not only a very limited set or a single architecture. However, we are not defining architectures in the IETF in general and in particular in PPSP.

  Martin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ye Wang
Sent: Tuesday, November 29, 2011 7:13 AM
To: 'Rui Cruz'; [email-masked]
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi Rui,

For example, we encounter a similar problem as what Rui mentioned, when we need to supporting dynamical multi-rate streaming (e.g., 240p, 360p, 480p, 720p HD).  We need to customize our protocols to make our system working more efficiently: in particular we decide to map different video chunks (from different sources, with different sizes) to the same id, based on corresponding video frame timestamp.
Another example is regarding the debate on the push/pull of the bitmap.  When our system works with low-capacity video source (e.g., a single server) and small chunk size, we build an overlay network with multi-hop diameter, and it turns out the push scheme performs better as it is an efficient way for the peers to discover the newest/rarest chunks in the channel, even though it consumes around 10% of the peer upload capacity; but when we have large-capacity source (e.g., a set of CDN access points) and large chunk size (e.g., to accommodate HTTP overhead when working with CDN), the pull based scheme actually saves peer uplink resource, since the overlay structure is not "deep", so each peer just need to request neighbors about their chunk availability "on demand" (as long as their neighbor's capacity is already efficiently utilized) because it can always fetch from source if it is not happy about the progress.

Thanks,
Ye

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Rui Cruz
Sent: Monday, November 28, 2011 7:18 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Rui Cruz
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi,

However...

1. Architecture

2. Wire Protocol

3. Message Transport

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section

Dear all,

With best regards

 Yunfei and Martin
    PPSP co-chairs

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 15:13:53 +0000

Hi Richard, 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Y.
> Richard Yang
> Sent: Tuesday, November 29, 2011 8:13 AM
> To: [email-masked]
> Cc: LANS Yale

Well, maturity is an indicator how far a proposal is. The discussions at the meeting have shown that there many fundamental questions which are not answered or addressed by draft-gu-ppsp-peer. For instance, if the protocol aims at a low footprint on the wire which allows for instance piggy backing of chunk maps (whatever the flavor of the maps are).

One discussion I remember well, was the discussion about how chunk maps are acutally exchanged between two peers:
- demand driven: a peer sends a chunk map request to the other chunk and waits for the response;
- piggy backed without explicit request: the peers include periodically chunk maps in the messages exchanged to update the other peer. 

The latter approach is clearly to be preferred, as speed matters, i.e., do not waste time to figure out that you need an update of the chunk maps, but let the peers to exchange that information on regular time basis. 

> period. Hence it is important to consider the key technical design. I

I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol proposals and the merged document raises even more questions than the predecessor documents. 

> works, as HTTP is really the thin waist of the Internet now. It will be

HTTP is a technical no go in time sensitive applications. It is also a no go for applications that require bi-directional communication. 

> We should consider more browser-native protocols, if possible, for ppsp

RTCWEB is putting things in the browser, namely VoIP. However, they are heavily relying on RTP to exchange the time sensitive information, i.e., voice and video. This is not supporting your argument at all. 

> * Are there any experimental results of swift at large scale real

To my understanding there are experimental results. You might argue about what large scale is. 

> of the protocol needs careful thinking.

This has been part of the discussions at the meeting. For instance, the chunk trading mechanism must be extensible. 

> that they are necessary. For example,

The draft describes the swift implementation right now and needs definitely work. 

> have impacts on the selection?

If you know about IPR you must declare it. See the IETF IPR rules. 

The usage of merkle trees or other mechanisms will be possible in the peer protocol, but there will be also the possibility to use other mechanisms. 

> information can be helpful.

I think the swift guys have papers about it. 

> mature design, if the authors are willing, before we make a decision.

Why? There has been time and we need to make a decision at some time point about the peer protocol and also the tracker protocol. 

We can of course wait until the next IETF meeting, but this sort of a bet towards the future. 

> to leave enough design space); make sure it is extensible in the message

I guess, it is up to you to raise technical details which be answered technically by the swift guys. 

  Martin

---

From: Arno Bakker <[email-masked]>
Date: Tue, 29 Nov 2011 16:19:05 +0100

On 29/11/2011 01:17, Rui Cruz wrote:
>
> *Alternative 1:* one draft would proceed describing the Protocol
> Architecture, Semantics, Syntax and Logic, and the other draft the way
> to implement the Wire Format/Encoding layer and Message Transport layer,
> suggesting and justifying Network Transport preferences.

Hi

the SARACEN project obviously has an architecture already specified, so 
by all means determine what things you need from the peer protocol to 
implement this architecture. I'll clarify a few points about swift below.

>  From what is written in the swift description draft, there is no
> interaction with the Media Player apart from feeding it with the

In Section 8 of the swift proposal, on Extensibility we discuss how we 
support different chunk/piece selection policies. So swift will support 
custom chunk selection algorithms that can be plugged into the base 
protocol and which determine what chunks are downloaded from whom.

>
> About the support of Structured Media, I could not see evidence of that,

One such chunk selection algorithm can be one that understands SVC. In 
the simplest case there is a metadata specification that tells the 
SVC-aware algorithm what layers there are and how they map to chunk IDs.
E.g. layer 0 is chunks 0..1000, layer 1 is chunks 1001...2001, etc.
Then, based on information from the base protocol about bandwidth and 
chunk availability the SVC-aware algorithm will select the chunks for 
the layers it can support.

We've been publishing on SVC/MDC and P2P since before 2004. As a matter 
of fact Riccardo is presenting a paper on chunk selection next week at 
IEEE ISM2011, so we know about structured media ;o)

	Riccardo Petrocco, Michael Eberhard, Johan Pouwelse and Dick 	
	Epema, "Deftpack: A Robust Piece Picking Algorithm for Scalable
	Video Coding", IEEE International Symposium on Multimedia 	
	(ISM2011), Dana Point, CA, USA, December 5-7, 2011.

CU,
     Arno

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 15:25:36 +0000

Hi Yingjie, 

> From: Yingjie Gu(yingjie) [mailto:[email-masked]]
> Sent: Tuesday, November 29, 2011 1:58 PM
> To: Martin Stiemerling
> Cc: [email-masked]
> Subject: 答复: [ppsp] Selection of PPSP peer protocol draft
> 
> We began to propose Tracker and Peer protocol at early 2010. Since the very
> beginning, we believe that Peer protocol should be consistent with Tracker
> Protocol. By consistence, I don't mean that they can co-exist, instead they
> should share the similar philosophy and should be able to interoperate.  That's
> why we call them a system, not two single protocols.

Aehm, we do not define systems here. We do define protocols. 

Anyhow, there is nothing against having two different sets of core people working on the tracker protocol and the peer protocol. We have the working group which will take care that the both can interact. 

Furthermore:
- the PPSP tracker protocol is optional to the PPSP peer protocol and
- the PPSP peer protocol is optional to the PPSP tracker protocol. 

The peer protocol must be able to operate without the tracker protocol, as an actual implementer of p2p tv system may chose a different way of distributing the information about other peers, e.g., via a DHT or via the regular bittorrent tracker protocol. 

The tracker protocol must be able to operate without the peer protocol, as somebody might chose to use the PPSP tracker protocol with a proprietary peer protocol.

> 
> PPSP had spent a lot of time on discussion on whether the PPSP standards
> should use Tracker-based or Full-mesh architecture (finally, WG got consensus
> on tracker-based), and how the Tracker and Peer protocol should work, which is
> in the Requirements draft. We always regards the requirements draft as a
> guidance on Tracker and peer protocol. Based on the requirements draft, we
> proposed draft-gu-ppsp-tracker-protocol and peer-protocol.

This sounds as your proposal for both protocols is authorative, because your proposal is based on the requirements draft. I would say that any protocol proposal is about to follow the requirements. 

> 
> The WG has spent a lot of effort on PPSP Survey, because we want to extract
> common features on current PPSP system, instead of base on a single private
> protocol.

What is the conclusion??

> 
> I agree that Swift works, and it is a research project supported by many
> research groups, and I think those show support for swift are mostly involved in
> SWIFT project.
> It will be easier for PPSP to get to an RFC published if we defining a protocol
> based on a mature private protocol. But what about other private protocols?
> ANY ONE of the protocols introduced in Survey draft can work well and most of
> them have much huge number of users than SWIFT, and even much better
> performance. Shall we take them into consideration?

Well, we potentially could go and examine all proprietary protocols out there, including the attached IPR and the willingness of the protocol owners to transfer the protocol to the IETF. 

This will keep us busy for another 1 or 2 years without being able to progress the specification of the protocols. 

> 
> I hate to make this selection as an attack on each other draft. And I hope those
> from SWIFT won't look at my email as an attack to their protocols. I just wonder
> what does PPSP WG want, a mature private protocol or a developing protocols
> based on widely survey?

The WG must do the selection based on technical arguments. It is not about attacking the other drafts, but to find out what is the best technical solution. 

And technically speaking, your peer protocol draft lacks a lot of details, as compared to the swift draft. 

However, to repeat this again:
If there are features in your protocol draft which are missing in the swift proposal, write them up and post them to the list. 

  Martin

---

From: Arno Bakker <[email-masked]>
Date: Tue, 29 Nov 2011 16:30:12 +0100

On 29/11/2011 07:12, Ye Wang wrote:
> When our system works with low-capacity video source (e.g., a single
> server) and small chunk size, we build an overlay network with multi-hop
> diameter, and it turns out the push scheme performs better as it is an
> efficient way for the peers to discover the newest/rarest chunks in the
> channel, even though it consumes around 10% of the peer upload capacity;
> but when we have large-capacity source (e.g., a set of CDN access
> points) and large chunk size (e.g., to accommodate HTTP overhead when
> working with CDN), the pull based scheme actually saves peer uplink
> resource, since the overlay structure is not “deep”, so each peer just
> need to request neighbors about their chunk availability “on demand” (as
> long as their neighbor’s capacity is already efficiently utilized)
> because it can always fetch from source if it is not happy about the
> progress.
>

Hi

if you have the need for a GET_HAVE/GET_CHUNKMAP message we can add that 
to swift, no problem. A complex problem, however, is to determine when 
to switch from push to pull based, as capacity at the source will vary 
depending on the number of peers in the swarm. Did you already design a 
solution for that?

CU,
     Arno

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 15:38:15 +0000

> From: Y. R. Yang [mailto:[email-masked]]
> Sent: Tuesday, November 29, 2011 3:08 PM
> To: Yingjie Gu(yingjie)
> Cc: Martin Stiemerling; [email-masked]
> Subject: Re: [ppsp] 答复: Selection of PPSP peer protocol draft
> 
> 
> 
> > I hate to make this selection as an attack on each other draft. And I hope
> those from SWIFT won't look at my email as an attack to their protocols. I just
> wonder what does PPSP WG want, a mature private protocol or a developing
> protocols based on widely survey?
> 
> I would like to second Yingjie's question. It is important to discuss the objective
> first. There are indeed other options, e.g., based on reverse engineering, ppsp
> could use as a base one of those extremely widely deployed (with tens of
> millions of real users) protocols, as long as there is no IP issue.

This will effectively postpone the PPSP peer protocol until infinity. 

We have agreed in the WG to make a decision for a peer protocol around the IETF-82 meeting, based on the proposals available at this time. 

> 
> Protocol design is not an optimization problem, i.e., pick the optimal protocol.
> So what is the goal of ppsp? If time is the essence and the goal is to have a peer
> protocol coming out of IETF quickly, then swift can be a starting base.

I personally want a protocol that I can implement in the next 12 months. And swift makes me feel that I will be able to do this. When reading draft-gu-ppsp-peer... I'm, not sure that I will be able to implement this in the next 12 months. For instance, where is the start of the state machine in the draft??

  Martin

> Tanenbaum talked about the timing of standardization based on a camel shape.
> I feel that p2p streaming is already at the lower half of the body, i.e., many
> commercial protocols already exist. I am wondering on the opinions of the
> chairs and other seasoned IETFs on an approach that PPSP could take, to make
> a difference. I understand that many want to discuss the specific technical
> details, but then I see endless debates.
> 
> Thanks!
> 
> Richard
> 
> >

---

From: Martin Stiemerling <[email-masked]>
Date: Tue, 29 Nov 2011 15:41:08 +0000

[speaking as PPSP WG chair]

> Subject: Re: [ppsp] 答复: Selection of PPSP peer protocol draft

[...]

> details, but then I see endless debates.

The work in the IETF is progressed about technical discussions, since we are engineers. Discussions about commercial viability are outside of the scope of the IETF. There is an old saying in the IETF "Let the market decide". 

With respect to Tanenbaum and Camels: I'm not sure in what stage p2p streaming is. I know that we are here to standardize PPSP and that we are supposed to get it done in a reasonable time frame. 

  Martin

---

From: "Y. Richard Yang" <[email-masked]>
Date: Tue, 29 Nov 2011 12:14:58 -0500

Hi Martin,

> The latter approach is clearly to be preferred, as speed matters, i.e., do not waste time to figure out that you need an update of the chunk maps, but let the peers to exchange that information on…
Yes. Piggybacking recent chunk availability update is a good idea (with 
low overhead). We found that this is important when we were designing 
SplendorStream, an Adobe Flash browser based P2P streaming system that I 
am involved with. As a technical feature, I feel that it should be 
supported. But I do not think that the discussion at this stage is on 
specifying such individual, specific features. As examples, however, 
they are excellent examples.

An important feature of the peer protocol, I think, is that it should 
support a multiplexing scheme between a single pair of IP/port (peer A 
<-> peer B). If we call this a session, a session is bidirectional, with 
multiple message types going through. In the general case the session 
can mark different priority, different reliability, in-out-of order 
delivery for the messages. Those are things that I would want.
> I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol proposals and the merged document raises even more questions than the predecessor documents.
I am not sure what view you are opposing... Maturity cannot change in a 
relatively short time period? Or you think that gu-peer has its chance 
already and hence it is time to make a decision to move on, now? But I 
guess this is non-technical. So we can skip, follow your order :-)
> RTCWEB is putting things in the browser, namely VoIP. However, they are heavily relying on RTP to exchange the time sensitive information, i.e., voice and video. This is not supporting your argumen…
To clarify, what I prefer is a protocol that is easier to be put into 
browsers, as this is more likely a deployment case. Let's change the 
name HTTP to web based. Will PPSP peer protocol consider coordination 
with the RTCWEB effort?
> If you know about IPR you must declare it. See the IETF IPR rules.
you == I (Richard Y :-) or the swift authors? The IPR might be held by 
others. The idea of hash tree was used in multiple settings, at least 
starting from 1998. My question is if someone (e.g., CK Wong, Simon Lam) 
holds an IP on it, will it have any influence on its selection (at least 
the process)?

Thanks.

Richard

---

From: Picconi Fabio <[email-masked]>
Date: Tue, 29 Nov 2011 19:09:49 +0100

Hi,

It's difficult to chose which mail to reply to with so many mails in the list today. :-)

Here are my comments. First, some important things which neither the Gu nor the Swift protocol seem to support:

1) Pull-token [1] or pull-push [2] streaming. The former is an approximation of push-based streaming, which works better than pull-based when the bottleneck is the uploader's bandwidth (which is typically the case). The latter is a hybrid between pull and push which achieves very low video lag with respect to the source. If PPSP is to support a wide range of chunk scheduling algorithms, then I believe it should support pull, pull-token and pull-push-based streaming.

2) View-Upload Decoupling [3]. VUD greatly reduces the impact of churn. Even if PPSP does not make this mandatory, I think the protocol should support this as an extension, or at least be designed such that the next version of the protocol can support VUD with much pain.

3) Substreams. This is a powerful feature. You can easily support SVC, MDC, multiple audio tracks, etc. if your protocol supports substreams. I think PPSP should support this.

Now, regarding the Gu-vs-swift diatribe:

1) Swift strives to achieve low playback latency (by using tricks such as piggybacking HAVE messages during handshake, etc.). I don't think this is that important. In commercial applications we can expect peers to start playback immediately by downloading from a CDN, and move to P2P connections once they're established. In any case, the first requests of Figure 2 of the Gu draft (before GET_CHUNK) could certainly be merged into a single request to save time.

2) Merkle trees are certainly a good choice for VoD, but I'm not convinced they're always the best solution for live streaming. If source lag is critical, then individually signing each chunk will give you the lowest lag (at the cost of extra CPU load due to signatures). If bandwidth is critical, the "sign-and-correct" method [4] will consumes less bandwidth than Merkle trees at the expense of a slight increase in lag. I guess what I'm saying here is that maybe we should not force a given integrity verification mechanism on PPSP.

3) I agree with Enrico that using HTTP is a bad idea. I only see disadvantages: you're forced to use TCP (i.e., you cannot chose another congestion control algorithm, in-order delivery increases delay, and retransmissions probably waste bandwidth), no bi-directionality, difficult NAT traversal, no existing HTTP cache or proxy infrastructure to leverage here. Conversely, UDP brings you several advantages: chose your congestion control, ignore lost packets, STUN-like NAT traversal. And I don't see any reason to use HTTP over UDP.

That's is for now.

Fabio

[1] F. Picconi and L. Massoulié. Is there a future for mesh-based live video streaming? In P2P, 2008.

[2] M. Zhang, Q. Zhang, L. Sun, and S. Yang, Understanding the Power of Pull-based Streaming Protocol: Can We Do Better? In IEEE JSAC, special issue on Advances in Peer-to-peer Streaming Systems, 2007.

[3] D. Wu, C. Liang, Y. Liu, and K. Ross. View-Upload Decoupling: A Redesign of Multi-Channel P2P Video Systems. In INFOCOM, 2009.

[4] P. Dhungel, X. Hei, K. W. Ross, and N. Saxena. The pollution attack in P2P live video streaming: measurement results and defenses. In P2P-TV, 2007.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rui Cruz
Sent: mardi 29 novembre 2011 14:26
To: Y.Richard Yang
Cc: Rui Cruz; [email-masked]; LANS Yale
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi Richard,

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section
Vice-Chair
IEEE Computer Society Portugal Chapter
[email-masked]<x-msg://127/[email-masked]>
[email-masked]<x-msg://127/[email-masked]>

Hi all,

Thanks!

Richard

Dear all,

With best regards

  Yunfei and Martin
     PPSP co-chairs

---

From: Njaal Borch <[email-masked]>
Date: Tue, 29 Nov 2011 19:16:28 +0100

As swift is based on a tree structure for hashes, requests and
availability, high speed connections can move the exchanged messages to
higher levels. In other words, peers can dynamically adjust both request,
hash checks, acks and have messages pr connection as they see fit, reducing
overhead when connections are good while keeping control when connectivity
is less good. In my opinion, local decisions are king in p2p networks, and
simple will almost always beat complex.

Regards,
N

On Nov 29, 2011 4:28 PM, "Arno Bakker" <[email-masked]> wrote:

> to swift, no problem. A complex problem, however, is to determine when to
> switch from push to pull based, as capacity at the source will vary
> ______________________________**_________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/ppsp<https://www.ietf.org/mailman/listinfo/ppsp>
>

---

From: Johan Pouwelse <[email-masked]>
Date: Tue, 29 Nov 2011 19:56:23 +0100

Reply inline...
On 29 November 2011 19:09, Picconi Fabio <[email-masked]> wrote:
> 1) Pull-token [1] or pull-push [2] streaming. The former is an approximation
> of push-based streaming, which works better than pull-based when the
> bottleneck is the uploader’s bandwidth (which is typically the case).  [snip]

Very true. At this stage we need to select one of the 2 peer
protocols. Making it "better-then-perfect" is a job for 2012 I guess.
With our real-world usage of streaming technology, we found that a
solid implementation is at least as valuable as a
sophisticated/(simple) algorithm.
Hopefully we can start an organised venture test various approaches.
In my opinion Libswift is push/pull agnostic and should support all.

> 2) View-Upload Decoupling [3]. VUD greatly reduces the impact of churn. Even
> if PPSP does not make this mandatory [snip]

Yes, the Libswift architecture is implicitly designed for this
important use-case.
We (the people behind Libswift) are very aware of the View-Upload
Decoupling work.
In 2006 we got an implementation working called 2Fast:
http://pds.twi.tudelft.nl/~pawel/pub/2fast_p2p.pdf

> 3) Substreams. This is a powerful feature. You can easily support SVC, MDC,
> multiple audio tracks, etc. if your protocol supports substreams. I think
> PPSP should support this.

Yes, very true. Powerful stuff. Once we converged on a single peer
protocol, it's time to create optional SVC/MDC expansions.
This technology is now slowly getting a bit mature, for instance, the
work on the ISO Standard (ISO/IEC 23009-1) .

Greetings, johan.

---

From: Picconi Fabio <[email-masked]>
Date: Tue, 29 Nov 2011 20:47:56 +0100

I'm not sure that Swift is push/pull agnostic.

Swift HINTs resemble download requests (as in pull-based systems), but they're not because the uploader is not forced to serve them.

I would say Swift resembles more a push-based system, because the uploader makes a peer/chunk scheduling decision based on some information it has about its neighbors (in this case, the HINTed chunks). In fact, HINTs resemble the pull-token mechanism that I mentioned in my previous email, which is an approximation of a push-based system. The difference is that the pull-token mechanism allows for a better-informed (and thus more useful) chunk selection, at the cost of an additional RTT due to signaling.

By the way, I find it weird that peers cannot UNHINT a HINTed chunk. Or maybe I missed something. UNHINTing chunks would be useful if the peer wants to request an already HINTed chunk from a different peer (e.g., if that chunk is still missing and it is getting dangerously close to the deadline). 

Fabio

-----Original Message-----
From: Johan Pouwelse [mailto:[email-masked]] 
Sent: mardi 29 novembre 2011 19:56
To: [email-masked]; Picconi Fabio
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Reply inline...
On 29 November 2011 19:09, Picconi Fabio <[email-masked]> wrote:
> bottleneck is the uploader's bandwidth (which is typically the case).  [snip]

Greetings, johan.

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 21:24:30 +0000

Hi Martin,

Read inline please....

> I oppose this view, as draft-gu-ppsp-peer is already a merger of 2 protocol proposals and the merged document raises even more questions than the predecessor documents. 

The only explicit mention to a merger of 2 proposals are related to the Tracker protocol, not to the Peer Protocol.
Nowhere in the gu-ppsp-peer draft nor in the corresponding presentation at the iETF meeting, is mentioned any merger of two previous peer protocol proposals. 
The only "merger" that happened related with the Peer Protocol was of the people working on the draft. 

Unfortunately, due to time limitations, it was not possible for us to write all the details we were willing to write in that draft document, hoping that the discussion during the WG meeting would allow us to capture the "advantages", the "features", the "extensions", etc. considered as suitable for the improvement of the design.

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 22:29:59 +0000

Hi, 

See comments inline.

> nodes run HTTP servers does not allow the creation of lightweight

Sorry but that is not correct. The draft DOES NOT uses HTTP as P2P protocol basis. 
Quote from the draft text: "The encoding for the signaling messages is not yet decided.  Two encodings are proposed, a Text-based (HTTP/XML) and a Binary-based described in Appendixes A and B. The authors will raise more discussion on the encoding, and will move the one that gets rough consensus of the PPSP WG to the draft text."

> [1] http://tools.ietf.org/html/draft-grishchenko-ppsp-swift-03

Best Regards,
Rui Cruz

---

From: Rui Cruz <[email-masked]>
Date: Tue, 29 Nov 2011 23:34:12 +0000

On 29/11/2011, at 15:19, Arno Bakker wrote:

> the SARACEN project obviously has an architecture already specified, so by all means determine what things you need from the peer protocol to implement this architecture. I'll clarify a few points about swift below.

Hi Arno,

The SARACEN project System architecture may use P2P for Media streaming, or not. And the SARACEN Platform architecture DID NOT determine the design of the P2P Streaming Protocols. It is in fact quite the opposite, as the P2P Streaming Protocols being developed have constrained the design of the Distribution Network of SARACEN System.

You could also say that the Swift protocol, was "determined" by/from the design of P2PNext project solution, as an alternative or an evolved mechanism. 

But I clearly stated in my message that "I am in favor of Swift as a Wire Format and Message Transport candidate for the PPSP Peer Protocol", and justified it technically, not politically.

> In Section 8 of the swift proposal, on Extensibility we discuss how we support different chunk/piece selection policies. So swift will support custom chunk selection algorithms that can be plugged into the base protocol and which determine what chunks are downloaded from whom.

Chunk/Piece selection policies, from your description, are algorithms at the Peer Agent level, not related with interaction with external applications like the Media Player, unless you consider the Media Player as an integral component of the Peer Agent, and all gets mixed up, protocols, policies, scheduling, media decoding, etc. 

What I said, is:  the Peer Agent should not decide by itself on starting the streaming process, but should respect at any moment the orders received from the Media Player to fetch the desired media (the chunks from a specific interval in the media timeline)  in the case of VoD. Apparently, swift, without a future extension is not yet capable of that interaction, meaning that a User, once triggered a stream has to watch it since the very beginning and is not allowed to select a future presentation time (go forward).

> One such chunk selection algorithm can be one that understands SVC. In the simplest case there is a metadata specification that tells the SVC-aware algorithm what layers there are and how they map to chunk IDs.

That is considering a single media container file with all layers in sequence in order to be split by byte ranges (chunks).
That does not solve the multiple representations (audio, video, subtitles), that should all be multiplexed in the container.
And that would require LARGE Chunkmaps at all the Peers, eventually very sparse (if Users were allowed to jump forward and backward in the media) 
How could the User select at any moment the desired representation to watch/hear/read?  

> Then, based on information from the base protocol about bandwidth and chunk availability the SVC-aware algorithm will select the chunks for the layers it can support.

So, the Peer is, once again, involved in media decoding process, not the Media Player Application.

> We've been publishing on SVC/MDC and P2P since before 2004. As a matter of fact Riccardo is presenting a paper on chunk selection next week at IEEE ISM2011, so we know about structured media ;o)

I am not arguing about your knowledge on Structured media, but on how the P2P Streaming Protocol supports (although not directly involved i decoding processes) Structured Media. 

But you did not answer my question for the example I gave of a content with multiple playable segments of complex structured Media.
How would swift stream such a content?

---

From: Rui Cruz <[email-masked]>
Date: Wed, 30 Nov 2011 00:05:31 +0000

Hi Martin,

Read inline please

On 29/11/2011, at 14:56, Martin Stiemerling wrote:

> I do not see how this will make a good protocol specification at the end. There must be one draft that contains everything so that an implementer can make a program out of this (or part of a program).

There are IETF protocols being specified in parts, as is the case of HTTPbis (7 parts).

> This requires that semantics and syntax are in the same draft for the protocol.

Semantics and Syntax can be applied at different levels of a protocol design. We may have Message semantics and syntax, well as request/response semantics, etc.

> Furthermore, there is no space for an architecture, as we do protocols.

I did not mention any system architecture, but the architecture of the protocol, in layers. Lowest layer addressing Message Transport, following layer addressing Wire Framework (service-side and transport-side) and the upper layer on protocol operation logic and semantics.

> There can be considerations how the protocol would interact with the rest of the program, i.e., the actual media player. But this is not part of the protocol specification.

Indeed there is the need for considerations on how the protocol might interact with other components either the Peer program or other external applications (not just the media player). Definitely these considerations are not part of the protocol specification, but described later, for instance, in usage guides and scenarios of application.
However, these consideration if included in drafts of the design, may serve initially as guidance.

>  
> Alternative 2:
> I do not see the common ground of the 2 proposals that would allow a merger.

What I said was related to a joint effort that would, in my opinion, accelerate the design. 
That happened for the Tracker Protocol, which, as you said, is on the right track for a WG draft. Two teams decided to combine their efforts and jointly are producing the draft specification.

> As stated in the meeting: draft-gu-ppsp-peer-protocol lacks many crucial details for specifying a peer protocol for PPSP.

Indeed, both drafts have several rough corners. 

>  
> I’m in clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer protocol. The protocol specification defines semantics and syntax. The defined semantics and syntax are what I understand and would be able to start working on an early implementation, though there is the need to get more things nailed down.

I also said that I am in favor of swift (not the draft) for the "Wire Format and Message Transport candidate for the PPSP Peer Protocol". The draft has several rough corners and constrains...

> But a proposal must not be perfect at this point of time.

Indeed! The draft-gu-ppsp-peer-protocol is not perfect but the authors are willing to improve the design in message definition, operation logic and semantics, extensibility, interactions, etc. 
And can perfectly see swift as the base for the Wire format and Message Transport of the Peer Protocol. Why not working together?

> The WG should consider elements of draft-gu-ppsp-peer-protocol as further input to the peer protocol.

You recognize that there are elements of interest in draft-gu-ppsp-peer-protocol. 
As you said in other message "PPSP protocols should fit a wide range of peer-to-peer TV architectures and not only a very limited set or a single architecture" and I fully agree, as I can see some elements in draft-grishenko-ppsp-swift that would constrain the peer protocol to a limited set of P2P TV architectures.

---

From: Arno Bakker <[email-masked]>
Date: Wed, 30 Nov 2011 09:41:05 +0100

> * Are there any experimental results of swift at large scale real

Hi Richard

we test swift using manifold testing with up to 200 emulated peers, with 
varying network configurations. We have plans to conduct another 
experiment with the WikiMedia foundation, and Yunfei, the co-chair is 
willing to conduct experiments with the PPSP peer protocol with 
ChinaMobile customers.

> of the protocol needs careful thinking.

IMHO, the protocol should provide the mechanisms that support many 
different policies (chunk selection, peer discovery & selection, etc.), 
without becoming overly generic. The latter is the complex bit ;o)

>      - page 4 top: "... peer connects to a random set of other peers ..."

I think I wrote random to distinguish swift from strictly tree-based 
protocols. Peer selection is pluggable in swift, to also allow input 
from e.g. ALTO servers.

> decisions often are better, faster decisions.

The reason why we don't have explicit CHOKE/UNCHOKE is because in 
practice they do not guarantee that a peer will actually send you data 
(the "snubbed" syndrome). Hence, we decided to go with observed 
behaviour (if a peer responds, fine, ask more, otherwise leave it).
But apparently you feel differently?

> such a push-just-received model may not be necessary.

We needed push-just-received in our current chunk-selection policies for 
live and VOD. We have to look into Fabio Picconi's remarks about 
lastest-useful policies for live that may not need it. In which 
situations does your system use another policy?

>      - The design is essentially pushing for an uploader centric design.

Can you elaborate a bit on that, I'm not sure what you mean. Normally, 
receivers explicitly request chunks via HINTs. Swift allows for live 
streaming protocols which push chunks.

> http://www.cs.utexas.edu/users/lam/395t/slides/DigitalSignature.pdf

Wesley Eddy, the transport area director already contacted the SEC area 
directors about it. Apparently there was a patent that might have 
covered the hash tree as we use it (I am not a lawyer), but it expired, 
no. 4,309,569:

http://patft.uspto.gov/netacgi/nph-Parser?Sect2=PTO1&Sect2=HITOFF&p=1&u=%2Fnetahtml%2FPTO%2Fsearch-bool.html&r=1&f=G&l=50&d=PALL&RefSrch=yes&Query=PN%2F4309569

In any case, it is the desire of the working group to support multiple 
methods of chunk addressing and content integrity protection (and I am 
rewriting the draft to reflect this), so patents do not impact selection.

> information can be helpful.

The binmap representation is described and compare to others in
http://www.pds.ewi.tudelft.nl/fileadmin/pds/reports/2011/PDS-2011-005.pdf
And, the new draft will allow different addressing methods, as just 
mentioned.

CU,
     Arno

---

From: Arno Bakker <[email-masked]>
Date: Wed, 30 Nov 2011 09:53:15 +0100

On 29/11/2011 14:26, Rui Cruz wrote:
 >
> And if the encoded complex structured media is segmented in rather large
> sized chunks (of 10x or 100x KiB) *each chunk* would have to be mapped,
> I suppose, to a quite large Hash tree to split the data in byte ranges
> for the datagrams. So, instead a a single Bin tree, a complex Structured
> Media with a duration of an hour (3600 seconds) would require at least
> 18000 Root hashes for chunks with 2 seconds encoded in 10 layers. Would
> this not be overkill?
>

Hi

I don't quite follow what you mean here. If the content consists of 1800 
intervals encoded in 10 layers, there will be 18,000 addressable chunks 
of content. In the simplest case in swift, these are mapped into a 
single tree with 18,000 hashes as leaves that is identified by a single 
root hash. As 18,000 hashes consume about 360 kilobytes with 20-byte 
SHA1 hashes, I'd hardly call that overkill.

Please explain how you intend to do content integrity protection in this 
case.

Regards,
     Arno

---

From: Arno Bakker <[email-masked]>
Date: Wed, 30 Nov 2011 10:25:18 +0100

> name HTTP to web based. Will PPSP peer protocol consider coordination

I've promoted PPSP at the Quebec IETF meeting of RTCWEB and the mailing 
list ("what if a client has insufficient upload to send his signal to 
all meeting participants") but the response I got was that they didn't 
want to look at that in the first iteration.

More promotion needed at a later stage. In the mean time, Firefox, 
Safari and IE allow the definition of additional transports via plugins. 
We have currently added swift as a protocol to Firefox, e.g.

<video 
src="tswift://tracker.p2p-next.org:20001/19cbe88150f7744e1fee6bd42f09c796a16929b1"/ 
controls="true" autoplay="true">

as demoed at the Taipei meeting.

CU,
     Arno

---

From: Arno Bakker <[email-masked]>
Date: Wed, 30 Nov 2011 11:37:46 +0100

On 30/11/2011 00:34, Rui Cruz wrote:
>
> But *I clearly stated* in my message that "*I am in favor of Swift as a
> Wire Format and Message Transport candidate* for the PPSP Peer
> Protocol", and*justified it technically*, not politically.
>

Let's move forward with swift then.

> Chunk/Piece selection policies, from your description, are algorithms at
> the Peer Agent level, not related with interaction with external
> applications like the Media Player, unless you consider the Media Player
> as an integral component of the Peer Agent, and all gets mixed up,
> protocols, policies, scheduling, media decoding, etc.
>

I don't think this mailing list is the right forum to discuss how to 
best software engineer P2P client software (trust me, we know how). All 
that matters for the WG is that swift supports pluggable algorithms, 
which receive information about the user's wishes on the one hand, and 
the (peer) network conditions on the other and select the chunks to 
download based on that.

> That is considering a single media container file with all layers in
> sequence in order to be split by byte ranges (chunks).

The swift protocol specification does not say anything about how chunks 
are mapped to disk, one could easily have a file per layer or track for 
SVC implementations. Or alternatively, use multiple swarms, as they are 
cheap in swift (cf. separate audio and video transmission in RTP).

> That does not solve the multiple representations (audio, video,
> subtitles), that should all be multiplexed in the container.

A different representation would be like a different layer and the 
SVC-chunk selector would know where in the chunk range they are mapped.
As said above, the chunk selector is informed about the user's choices
regarding seeking, language, etc.

> But you did not answer my question for the example I gave of a content
> with multiple playable segments of complex structured Media.

I refer you to Riccardo's IEEE ISM2011 paper, as I think this is too 
detailed to discuss here, unless someone disagrees. Here is a draft version:
http://svn.tribler.org/abc/branches/riccardo/SLaPP/layeredPP.pdf

Regards,
     Arno

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 30 Nov 2011 14:59:29 +0000

Hi Richard, 

> holds an IP on it, will it have any influence on its selection (at least

Everybody who is aware of patent relating to the PPSP protocols must declare it. 
I have no knowledge if Wong or Lam have IPR on it. 

  Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 30 Nov 2011 16:09:13 +0000

Hi Rui,

From: Rui Cruz [mailto:[email-masked]] On Behalf Of Rui Cruz
Sent: Tuesday, November 29, 2011 10:25 PM
To: Martin Stiemerling
Cc: Rui Cruz; Y. Richard Yang; [email-masked]; LANS Yale
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi Martin,

Read inline please....

Yes, indeed. I have mixed up the tracker and the peer protocol. Sorry for that.

I would be delighted to see contributions on features on the mailing list or in an updated draft.

  Martin

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 30 Nov 2011 16:15:48 +0000

Hi Rui,

Now the email with text...

I think we are on the same side, let's work together.

What I would like to see, that people review both protocols and state what they see is missing, so that this will be documented on the list.

  Martin

From: Rui Cruz [mailto:[email-masked]] On Behalf Of Rui Cruz
Sent: Wednesday, November 30, 2011 1:06 AM
To: Martin Stiemerling
Cc: Rui Cruz; [email-masked]
Subject: Re: [ppsp] Selection of PPSP peer protocol draft

Hi Martin,

Read inline please

Hi there,

Alternative 2:

I'm in clear favor of draft-grishchenko-ppsp-swift as being the PPSP peer protocol. The protocol specification defines semantics and syntax. The defined semantics and syntax are what I understand and would be able to start working on an early implementation, though there is the need to get more things nailed down.

  Martin

Hi,

However...

1. Architecture

2. Wire Protocol

3. Message Transport

Prof. Rui Santos Cruz
Chairman
IEEE Portugal Section

Dear all,

With best regards

 Yunfei and Martin
    PPSP co-chairs

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 30 Nov 2011 16:55:36 +0000

Hi,

On 29.11.2011, at 22:24, "Rui Cruz" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Martin,

Read inline please....

Not according to this message sent to the list:
http://www.ietf.org/mail-archive/web/ppsp/current/msg01109.html

---

From: Rui Cruz <[email-masked]>
Date: Wed, 30 Nov 2011 17:07:25 +0000

On 30/11/2011, at 16:55, Martin Stiemerling wrote:
> 
> On 29.11.2011, at 22:24, "Rui Cruz" <[email-masked]> wrote:
> 
>> 

Indeed, that was a misleading sentence that does not correspond to the intention of the team. Sometimes being in a hurry creates these unfortunate situations.