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

[Xiajinwei <[e-mail]>]

Hi,

Please see my answer inline.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

> * 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)
> 

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.

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

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

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


Jinwei

> 
> Regards,
>        Arno Bakker
> _______________________________________________
> ppsp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ppsp