Subject: Re: [ppsp] 转发: New Version Notification for draft-gu-ppsp-peer-protocol-03.txt

From: Arno Bakker <[email-masked]>
Date: Wed, 2 Nov 2011 10:06:55 +0100

On 01/11/2011 02:21, Xiajinwei wrote:
> Hi,
>
> We have updated the PPSP Tracker Protocol draft, corresponding to the merge of the former drafts from Gu and Cruz.
>
> This version mainly focus on the messages exchanged between peers, but leave the encoding format into Appendix since using binary or HTTP/XML as container is still under dispute.
>
> Please let us know your comments and suggestions.
>

Hi

reading throught the sketch for the first time I have the following 
comments:

* The draft is inconsistent on how the actual chunks are transported: on 
the one hand the draft states that data will be transported via existing 
media transport protocols, on the other hand it defines a GET_CHUNK 
request that is replied to with actual chunks.

* Assuming existing media transports, I have some reservations about 
this design. It will mean that peers have to establish another 
communication path (e.g. HTTP connection) in addition to the signalling 
path. This means going through NAT firewall traversal procedures another 
time, and double resource usage (sockets+buffers). The former won't help 
in achieving a fast time-till-playback.

* When HTTP is used this may lead to 4 HTTP connections between every 2 
peers. One for signalling from A to B, one for data from A to B, one for 
signalling from B to A and one for data from B to A. These connections 
must also be established in the right direction, i.e., the client party 
must initiate the TCP connection. Assuming that peers should be 
contributing data to eachother as much as possible, having 4 connections 
will/should be a very common scenario.

* The protocol currently is fully pull-based. I have reservations 
whether this will result in low latency for live streaming and VOD 
time-till-playback. The authors should explain how they do achieve low 
latency. The protocol also needs optimization, in Figure 2 a number of 
synchronous requests are on the critical path for playback-start that 
need not be there.

* In addition, the protocol has only limited support for multiplexing 
and/or reducing communication round-trips. Ideally, peer A should be 
able to send its chunkmap to peer B on a GET_CHUNKMAP message. In the 
current sketch peer B has to send its own GET_CHUNKMAP. The binary 
encoding allows for multiplexing of multiple requests *or* replies into 
a single datagram, but not of requests *and* responses. The HTTP 
encoding doesn't cater for multiplexing at all.

* The sketch is incomplete in many ways. There are several TODOs and 
TBDs, some of which could be easily resolved, e.g. the transport 
negotation part can be written down precisely with RTP and HTTP as 
transport protocols. Also critical security components such as content 
integrity protection should be described.

* There are many technical quirks and undocumented design choices,
especially in the binary encoding. For example, the encoding requires
that all 8-bit data is encoded in the set of 94 ASCII printable 
characters. All packets starts with the key "PPSP" for reasons unknown. 
It allows just for IPv4 addresses (6.5-bit encoding issues apart). The 
swarm ID is apparently a 32-bit number. Peer IDs are 128 bits without 
explanation about their role and the size of their ID address space. 
Many fields take up much more bits than necessary, e.g. message-type (8 
bits for 2 values) and message-body-length (24 bits)

* As remarked before, I think HTTP is unsuited as the basis for
a peer-to-peer protocol. This is even illustrated in the draft itself: 
the PEER_STATUS message is needed for a serving peer to tell a client 
peer it can no longer request data. As unsollicited communication from 
server to client is impossible in HTTP, this design is either impossible 
or requires 2 HTTP connections per pair of peers. Note this quirky 
design is not necesarry when simply TCP is used.

I kindly request the authors to do better quality control on their 
documents, so we can focus on the complex design decisions and not be 
distracted by obvious flaws.

Regards,
       Arno Bakker

---

From: Njaal Borch <[email-masked]>
Date: Wed, 2 Nov 2011 10:28:55 +0100

Hi,
I find this proposal a study of overhead and incompleteness.  It
appears to fail in addressing pretty much all p2p issues, like nat
traversal, incentives, flow control, integrity and efficiency and
seems highly dependent on centralized services for tracking and
registration.  The fact that the suggested protocol does not open for
proper two-way information sharing (such as states, bitmaps etc) shows
that this is basically a client-server protocol with little
understanding of the fact that peers in a p2p network are best treated
as equals. The amount of small messages performed in a get/reply
fashion is in direct conflict with short startup times and gives no
other benefits over a minimal message exchange. Other suggestions,
like using XML over HTTP (over UDP) is a sure way to explode both
network overhead and processing time required by participating
devices, and leaving data integrity to an external solution is a
massive flaw - one cannot trust nodes in a p2p network, nor the links
they are using.

In my opinion this is a very incomplete proposal with little going for
it, and even with a lot of refinement, it will still be dependent on a
mass of other standards and systems, making it into a very complicated
and most likely non working solution.  Basically, the added benefits
of utilizing this protocol over existing P2P protocols seems not only
non-existing, but it rather is a proper step back from for example
streaming BitTorrent (which in itself is not a particularly good
protocol either). Other fundamental errors, like inflated numbers of
connections required (4 vs 1) and lack of generic P2P properties are
hardly easily addressed without a total rewrite of the protocol.

Regards,
Njål

---
Dr. Njål Borch
Northern Research Institute (NORUT)
Tromsø, Norway

On 2 November 2011 10:06, Arno Bakker <[email-masked]> wrote:
>> We have updated the PPSP Tracker Protocol draft, corresponding to the
>> merge of the former drafts from Gu and Cruz.
>>
>> This version mainly focus on the messages exchanged between peers, but
>> leave the encoding format into Appendix since using binary or HTTP/XML as
>> container is still under dispute.
>>
> * The draft is inconsistent on how the actual chunks are transported: on the
> one hand the draft states that data will be transported via existing media
> transport protocols, on the other hand it defines a GET_CHUNK request that
> is replied to with actual chunks.
>
> * Assuming existing media transports, I have some reservations about this
> design. It will mean that peers have to establish another communication path
> (e.g. HTTP connection) in addition to the signalling path. This means going
> through NAT firewall traversal procedures another time, and double resource
> usage (sockets+buffers). The former won't help in achieving a fast
> time-till-playback.
>
> signalling from B to A and one for data from B to A. These connections must
> also be established in the right direction, i.e., the client party must
> initiate the TCP connection. Assuming that peers should be contributing data
> to eachother as much as possible, having 4 connections will/should be a very
> common scenario.
>
> * The protocol currently is fully pull-based. I have reservations whether
> this will result in low latency for live streaming and VOD
> synchronous requests are on the critical path for playback-start that need
> not be there.
>
> * In addition, the protocol has only limited support for multiplexing and/or
> reducing communication round-trips. Ideally, peer A should be able to send
> its chunkmap to peer B on a GET_CHUNKMAP message. In the current sketch peer
> B has to send its own GET_CHUNKMAP. The binary encoding allows for
> multiplexing of multiple requests *or* replies into a single datagram, but
> not of requests *and* responses. The HTTP encoding doesn't cater for
> multiplexing at all.
>
> * The sketch is incomplete in many ways. There are several TODOs and TBDs,
> some of which could be easily resolved, e.g. the transport negotation part
> can be written down precisely with RTP and HTTP as transport protocols. Also
> critical security components such as content integrity protection should be
> described.
>
> that all 8-bit data is encoded in the set of 94 ASCII printable characters.
> All packets starts with the key "PPSP" for reasons unknown. It allows just
> for IPv4 addresses (6.5-bit encoding issues apart). The swarm ID is
> apparently a 32-bit number. Peer IDs are 128 bits without explanation about
> their role and the size of their ID address space. Many fields take up much
> more bits than necessary, e.g. message-type (8 bits for 2 values) and
> message-body-length (24 bits)
>
> a peer-to-peer protocol. This is even illustrated in the draft itself: the
> PEER_STATUS message is needed for a serving peer to tell a client peer it
> can no longer request data. As unsollicited communication from server to
> client is impossible in HTTP, this design is either impossible or requires 2
> HTTP connections per pair of peers. Note this quirky design is not necesarry
> when simply TCP is used.
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>

---

From: Xiajinwei <[email-masked]>
Date: Fri, 04 Nov 2011 01:22:58 +0000

Hi,

Please see my answer inline.

> request that is replied to with actual chunks.

GET_CHUNK is signaling message sent by leech peer to ask sender peer to send the chunk requested by leech peer, sender peer responds GET_CHUNK with success or failure notification. If it succeed, sender peer send the concrete data (chunk) whose ID is requested in GET_CHUNK by existing media transport protocol decided by transport negotiation.

> in achieving a fast time-till-playback.

It is a normal case that using different sessions to convey signaling and data, e.g., using SIP or RTSP to setup and control media session but using RTP to convey the media session data.

> will/should be a very common scenario.

It may not be true, if A has not the chunks in which B is interested, there is not signaling HTTP connection in the direction from B to A. If B is interested in the chunks on A, the draft-ietf-hybi-thewebsocketprotocol has defined a mechanism that realize the bidirectional HTTP communication between peer ( this draft is in RFC Ed Queue), it can address your above concern. Additionally, the data transmission is out of scope, we don't mention that using HTTP as data transport protocol.

> synchronous requests are on the critical path for playback-start that

The methods defined in the draft intends to provide a explicit description of information that needs to be exchanged between peers. But the methods can be combined in a single message, which can reduce the latency caused by synchronous requests.

> encoding doesn't cater for multiplexing at all.

See my previous response, it can also answer your next comment on multiplexing. For example, peer A can send a message with GET_CHUNKMAP with its PEER_STATUS and its CHUNKMAP within a single message.

> integrity protection should be described.

Agree, we will complement it in next version. As for the transport protocols, we can list some candidates protocols for consideration but we need to get rough consensus on WG before we can make any precise decision.

> bits for 2 values) and message-body-length (24 bits)

These parts (e.g., the length of Peer ID etc) are undecided and need to be discussed with corresponding experts, that is why we leave them as TBD.

> design is not necesarry when simply TCP is used.

I agree the description is confusing. this message is sent from leech peer to sender peer, please refer figure 2. I will revise the description, change serving peer to leech peer, and change client to sender peer.

> distracted by obvious flaws.

Thank your reminding, we will take care of it in future.

Jinwei

---

From: Arno Bakker <[email-masked]>
Date: Mon, 7 Nov 2011 13:21:47 +0100

Hi

my remarks are inline:

On 04/11/2011 02:22, Xiajinwei wrote:
> If it succeed, sender
> peer send the concrete data (chunk) whose ID is requested in
> GET_CHUNK by existing media transport protocol decided by transport
> negotiation.
>

Aha. Please make Figure 2 and the description of the GET_CHUNK message
on p. 12 more clear.

> It is a normal case that using different sessions to convey signaling
> and data, e.g., using SIP or RTSP to setup and control media session
> but using RTP to convey the media session data.
>

But in this case a client is potentially communicating with many peers
(so resource usage matters) and, more importantly, the signalling and
data transfer are tied together much more closely for PPSP.

> It may not be true, if A has not the chunks in which B is interested,
> there is not signaling HTTP connection in the direction from B to A.

A peer-to-peer system should be designed such that the upload capacity
of peers is exploited as much as possible. One method of doing so it to
ensure that when two peers meets they have some chunks to exchange.
BitTorrent, for example, achieves this by using the rarest-first
economic model. In this model, peers download the chunk that the least
number of peers have, such that it will have something that is of
interest to a great many peers. For live streaming it will hold in
general that peer A may have things that interest peer B because the
window of interest is small, everybody is interested in the chunks
recently generated by the live source. We have used this rarest-first
model successfully for video-on-demand and live streaming [1,2].

Apparently you are not using "ensured mutual interest" as the mechanism
to exploit peer upload capacity. Can you explain what mechanisms you do
intend to use to make peers upload to eachother?

> If B is interested in the chunks on A, the
> draft-ietf-hybi-thewebsocketprotocol has defined a mechanism that
> realize the bidirectional HTTP communication between peer ( this
> draft is in RFC Ed Queue), it can address your above concern.

Using bidirectional HTTP is a step not taken lightly, and a kludge IMHO.
A design of a protocol in which one first establishes a symmetric
TCP connection, then runs an asymmetric client/server
protocol and finally, runs a complex framing protocol over that to make
the connection symmetrical again needs a very strong justification.

So unless there is strong evidence (measurements) that establishing an
outgoing TCP connection is much harder in general than establishing an
HTTP connection, HTTP should not be considered as a transport protocol
for PPSP traffic, IMHO.

If there is such evidence, the IETF should really scratch their
collective heads as to how we wound up in a situation where we are
basically redefining TCP as websockets-over-HTTP :-(

> See my previous response, it can also answer your next comment on
> multiplexing. For example, peer A can send a message with
> GET_CHUNKMAP with its PEER_STATUS and its CHUNKMAP within a single
> message.
> 

Can you please elaborate on how your multiplexing works? When I look at
the binary encoding a datagram on the wire consists of the main message
header (p.16) followed by zero or more TLV (Type, Length, Value)
elements (p.18).

The main message header contains a "message type" field (p. 17) that is
either "Request" or "Reply". The Type in the TLV elements can be
GET_PEERLIST (value 1), GET_CHUNKMAP (value 2), GET_CHUNK (value 3),
GET_PROPERTY (value 4, and I guess you mean GET_STATUS) and
TRANSPORT_NEGOTIATION (value 5). I assume that a GET_CHUNKMAP request is
sent as a TLV element with Type=GET_CHUNKMAP and length 0, the spec is
not clear.

In any case, this design suggests that you can send multiple requests in
one datagram ("Message Type" = "Request"), and multiple replies, but not
a mix. In other words, how do I distinguish a GET_CHUNKMAP request from
peer A to B, from the actual chunkmap of A that it wants to send to B in
the same datagram?

The HTTP encoding does not discuss multiplexing at all, as far as I can
tell.

> Agree, we will complement it in next version. As for the transport
> protocols, we can list some candidates protocols for consideration
> but we need to get rough consensus on WG before we can make any
> precise decision.
> 

I think it is important to show how your design works with concrete
media transport protocols, and HTTP and RTP are explicitly mentioned in
the charter, and the obvious candidates. You are using HTTP already as
data transport on p. 28 ;o)

> These parts (e.g., the length of Peer ID etc) are undecided and need
> to be discussed with corresponding experts, that is why we leave them
> as TBD.
> 

Then please modify the specification. It currently makes explicit
choices without justification rather than leaving them TBD :-(

>> * As remarked before, I think HTTP is unsuited as the basis for a
>> peer-to-peer protocol. This is even illustrated in the draft
>> itself: the PEER_STATUS message is needed for a serving peer to
>> tell a client peer it can no longer request data. As unsollicited
>> communication from server to client is impossible in HTTP, this
>> design is either impossible or requires 2 HTTP connections per pair
>> of peers. Note this quirky design is not necesarry when simply TCP
>> is used.
>> 
> 
> I agree the description is confusing. this message is sent from leech
> peer to sender peer, please refer figure 2. I will revise the
> description, change serving peer to leech peer, and change client to
> sender peer.
> 

Err... no. On page 29 a serving peer uses GET_STATUS to choke a leecher.
That is, the server uses it to tell a client to stop requesting data
from it. You cannot simply reverse the direction here,
then you lose functionality.

This is a strong example that peer-to-peer communication is by nature
symmetrical and using an asymmetric protocol like HTTP will lead to an
awkward design.

Regards,
     Arno Bakker

==========
References

[1] J. Mol, J. Pouwelse, M. Meulpolder, D. Epema, and H. Sips,
“Give-to-Get: Free-riding Resilient Video-on-demand in P2P Systems,” in
Proceedings Multimedia Computing and Networking conference (Proceedings
of SPIE Vol. 6818), San Jose, California, USA, Jan. 2008.
[2] J. Mol, A. Bakker, J. Pouwelse, D. Epema, and H. Sips, “The design
and deployment of a bittorrent live video streaming solution,” in
Proceedings IEEE International Symposium on Multimedia 2009, San Diego,
CA, USA, Dec. 2009.