Subject: Re: [ppsp] WGLC for the survey draft

From: lingli deng <[email-masked]>
Date: Fri, 29 Nov 2013 01:35:25 +0800

Hi Yunfei and all,

I have the following comments about the current survey draft:

1, it states as a "standard track" document, is that accurate?

2, in terminoloy section, "push" is defined as "Transmission of multimedia
content without any request from receiving peers.", which I think could be
better described as "Transmission of multimedia content that is not
initiated by receiving peers."

3, In section 3, "the topology that can be associated with overlay
connections among peers" could be rephrased into "the topology of overlay
connections among peers".
4, Also in section 3, "pull-based data delivery calls for large size
buffers where to store chunks" could be rephrased into "pull-based data
delivery calls for large size buffers to store chunks".

5, "buffer-maps" are used to refer to "chunk availability information" (as
used by RFC 6972). For sake of consistency, I think it is better to use the
latter instead.

6, In Section 3.2.1 “channel server, that provides the list of available
channels (live TV or VoD content) to a PPLive, as soon as the peer joins
the system;” should be “channel server, that provides the list of available
channels (live TV or VoD content) to a PPLive peer, as soon as the peer
joins the system;”

7, It seems to me that the content server may have played some sort of
tracker’s role in Octoshape, otherwise, how would a joining peer gets to
know the initial address book of other peers?

8, In Section 3.2.3, “a mechanism very similar to the one of TCP congestion
window (double increase or linear increase depending on whether the
estimate is below or a given threshold)”, should be like “a mechanism very
similar to the one of TCP congestion window (double increase or linear
increase depending on whether the estimate is below or above a given
threshold)”

9, One may be curious about what is the difference between a “repeater
node” and a “simple peer”, as the description of a “repeater node” goes
like “Repeater nodes, that serve as bandwidth multiplier, are able to
forward any sub-stream and implement the same peer protocol as simple
peers.”

10, In Section 3.2.4, “a PPStream peer selects peers to download sub-chunks
from according to a rate-based algorithm” should be change into “a PPStream
peer selects peers to download sub-chunks according to a rate-based
algorithm”
11, In Section 3.1.5, “As already said, Tribler supports video streaming in
two different forms: video on demand and live streaming.” Is better to be
changed into “Tribler supports video streaming in two different forms:
video on demand and live streaming.”, since there is no prior statement in
the draft.

12, Also in Section 3.1.5, “Such a mechanism allows Tribler peers to use
the public key included in torrent file and verity the integrity of each
chunk.” should be changed into “Such a mechanism allows Tribler peers to
use the public key included in torrent file and verify the integrity of
each chunk.”

13, There is considerable reference and comparison to the Bitorrent
system/model in the Tribler’s subsection, one may wonder why not pose a
separate section for introduction of Bittorrent instead?

14, It is noticeable that both the Tribler’s peer selection algorithm and
security mechanisms are elaborated in such a detailed way? What about other
systems in terms of similar design issues? Since Section 3 is focus mainly
on the peer topology, maybe separate sections on algorithm/security are
more natural for better compression.

15, In Section 3.1.6, what does it mean by “not RTP/RTCP” in “the client
use UDP to transfer the encrypted media streaming and not RTP/ RTCP.”?

16, In Section 3.3.1, “Parent re-selection is also applied in case of
leaving of the previous parent.” Is better to be changed into “Parent
re-selection is also triggered for a peer when its previous parent leaves.”
17, From the description in Section 3.3.1, it is not clear to me why the
QQLive’s topology is a hybrid of mesh and tree.
BR
Lingli

-- 
邓灵莉/Lingli Deng
中国移动通信研究院/China Mobile Research Institute
e-mail: [email-masked]
tel: 15801696688-3367
mobile: 13810597148