Re: [ppsp] WGLC for the survey draft

[lingli deng <[e-mail]>]

Hi Francesca,


Thank you for the quick response.
I think most of the issues are addressed, except the security mechanisms.
(Inline comments are also included below^^)

The concern here is that I think security considerations is also important.
 Would it be possible to feed relevant content into “security
considerations” rather than simple removal?



BR

Lingli



*发件人:* ppsp [mailto:[e-mail]] *代表 *Francesca Lo Piccolo
(flopicco)
*发送时间:* 2013年12月4日 19:09
*收件人:* Zongning; duan; 'yunfei zhang'; Gu Yingjie; lingli deng
*抄送:* [e-mail]
*主题:* Re: [ppsp] WGLC for the survey draft



Duan and all,



I absolutely agree with you on the good quality of received feedback and on
the necessity to fix some parts in the survey draft.



To this end, I'm attaching a new revision of the survey (and also of the
pictures), where most of the comments from Rachel, Roni and Lingli have
been already taken into account.



Here is a summary of all the received comments, with the ones still open
highlighted in red. Lingli, you are among the "to" receivers, because there
is some your comment I would like to further discuss with you.



Rachel

---------

+ The description in the last paragraph of Section 1 is inconsistent with
the organization of chapters . This should be fixed. --> Ning, is it
possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and
subsections) in section 5 and 3.3 (and subsections) in section 6?

+ In section 2, some terminologies have already defined in RFC6972. It’s
unnecessary to repeat the definition, e.g., chunk, live streaming… --> done

+ Section 1 typo: “we always try to identity tracker and peer protocols”
should be “we always try to identify tracker and peer protocols” --> done

+ Section 3.1, typo “this may turn at end users into playback quality
degradation” should be “this may turn end users into playback quality
degradation” --> done

+ It’s better to adjust the order of types of P2P streaming applications to
be consistent with the order of subsections, which means “mesh-based”
should be first, then “tree-based”. --> done



Roni

------

+ Figure 1 “traker” should be “tracker”  --> done

+ In section 3.1.2 on PPLive change “being the nature of PPLive protocols
and algorithm proprietary” to “ Since the protocols and algorithm of PPLIVE
are proprietary”  --> done

+ In section 3.1.3 “ Authentication server is the first point of contact
for a peer the joins the system” to “Authentication server is the first
point of contact for a peer that joins the system” --> done

+ In section 3.1.3 “ can contact new more peers besides the ones indicated
by the rendezvous server” to “can contact new peers besides the ones
indicated by the rendezvous server” --> done

+ In section 3.1.5 “Since children could lie regarding the number of chunks
forwarded to others, Tribler peers do directly not ask their children, but
their grandchildren.” To “Since children could lie regarding the number of
chunks forwarded to others, Tribler peers do not ask their children
directly, but their grandchildren.” --> done

+ In section 3.1.6 when first using CDN expand to Content Delivery Network
(CDN) --> done





Lingli

-------

+ it states as a "standard track" document, is that accurate? --> Ning, we
already discussed about this. As per your comment, this document should be
“informational”, rather than “standard track”. I assume this is something
you can take into account as soon as you will submit the final revision,
right?

+ 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." --> done

+ 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".  --> done

+ 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". --> done

+ "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. --> I re-phrased "in some applications peers exchange chunk
availability information in form of buffer-maps (a sort of bit maps with a
bit "1" in correspondence of chunks stored in the local buffer)". Lingli,
have I got your point?

[dll] Yes. I am OK with this.

+ 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;” --> done

+ 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? --> done

+ 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)” --> done

+ 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.”  -->
I re-phrased "simple peers, whose behavior has already been presented, and
repeater nodes, that implement the same peer protocol as simple peers and
in addition are high-bandwidth peers and are able to forward any
sub-stream. In such a way repeater nodes serve as bandwidth multiplier".
 Lingli, have I got your point?

[dll] Yes. It works for me.

+ 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”  --> done

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

+ 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.” --> Lingli, I think your comment after the subsequent one is
correct. So I completely removed this part. See my observation later on. Do
you agree?

[dll] Plz see my comment below.

+ 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? Lingli, I don't
think this is the case, because Bit Torrent is a P2P file sharing system
and I have the impression that a section devoted to a P2P file sharing
system could appear somehow out of scope. In addition, every time Bit
Torrent is cited, we always tried to provide the necessary background info.
Does it make sense?

[dll] You are right, since Bittorent is not a streaming system, it seems
out of scope. It is a bad idea, forget it.

+ 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. --> Lingli, the main problem here is
that such a level of detail is often not available for all the
applications. Regarding this point I also added the following statement in
"Introduction" section "In addition, the provided descriptions may
sometimes appear inhomogeneous from the detail level point of view, but
this always depends on the amount of available information at writing time.".
 So the only solution seems to me to remove the reference to the security
mechanisms. The peer selection algorithm is full part of the peer protocol
in my opinion and it has to be kept. But i would like to hear from you.

[dll] I see your point. However, I would not agree that security is not as
important as peer selection algorithm. Would it be possible to feed it into
“security considerations”?

+ 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.”? -->
Duan, if I remember correctly, you provided this part. Can you please
explain?

+ 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.” --> done

+ 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.  --> Lingli, this comment
is not completely clear for me. Probably you meant New Coolstreaming. If
so, New Coolstreaming may be regarded as hybrid, because on the one side
you have an overlay mesh, on the other side you have as many trees as
substreams. I also added the following statement "Hence, the overall
overlay topology is mesh-based, but it is also possible to identify as many
overlay trees as sub-streams.". Is it clearer now?

 [dll] Sorry for the typo, I did mean New Coolstreaming. I am fine with the
clarification.


2013/12/4 Francesca Lo Piccolo (flopicco) <[e-mail]>

>  Duan and all,
>
>  I absolutely agree with you on the good quality of received feedback and
> on the necessity to fix some parts in the survey draft.
>
>  To this end, I'm attaching a new revision of the survey (and also of the
> pictures), where most of the comments from Rachel, Roni and Lingli have
> been already taken into account.
>
>  Here is a summary of all the received comments, with the ones still open
> highlighted in red. Lingli, you are among the "to" receivers, because there
> is some your comment I would like to further discuss with you.
>
>  Rachel
>  ---------
>  + The description in the last paragraph of Section 1 is inconsistent
> with the organization of chapters . This should be fixed. --> Ning, is it
> possible to turn section 3.1 (and subsections) into section 4 and 3.2 (and
> subsections) in section 5 and 3.3 (and subsections) in section 6?
>  + In section 2, some terminologies have already defined in RFC6972. It’s
> unnecessary to repeat the definition, e.g., chunk, live streaming… --> done
>  + Section 1 typo: “we always try to identity tracker and peer protocols”
> should be “we always try to identify tracker and peer protocols” --> done
>  + Section 3.1, typo “this may turn at end users into playback quality
> degradation” should be “this may turn end users into playback quality
> degradation” --> done
>  + It’s better to adjust the order of types of P2P streaming applications
> to be consistent with the order of subsections, which means “mesh-based”
> should be first, then “tree-based”. --> done
>
>  Roni
>  ------
>  + Figure 1 “traker” should be “tracker”  --> done
> + In section 3.1.2 on PPLive change “being the nature of PPLive protocols
> and algorithm proprietary” to “ Since the protocols and algorithm of PPLIVE
> are proprietary”  --> done
> + In section 3.1.3 “ Authentication server is the first point of contact
> for a peer the joins the system” to “Authentication server is the first
> point of contact for a peer that joins the system” --> done
> + In section 3.1.3 “ can contact new more peers besides the ones indicated
> by the rendezvous server” to “can contact new peers besides the ones
> indicated by the rendezvous server” --> done
> + In section 3.1.5 “Since children could lie regarding the number of
> chunks forwarded to others, Tribler peers do directly not ask their
> children, but their grandchildren.” To “Since children could lie regarding
> the number of chunks forwarded to others, Tribler peers do not ask their
> children directly, but their grandchildren.” --> done
> + In section 3.1.6 when first using CDN expand to Content Delivery Network
> (CDN) --> done
>
>
>  Lingli
>  -------
>  + it states as a "standard track" document, is that accurate? --> Ning,
> we already discussed about this. As per your comment, this document should
> be “informational”, rather than “standard track”. I assume this is
> something you can take into account as soon as you will submit the final
> revision, right?
>  + 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." --> done
>  + 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".  --> done
>  + 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". --> done
> + "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. --> I re-phrased "in some applications peers exchange chunk
> availability information in form of buffer-maps (a sort of bit maps with a
> bit "1" in correspondence of chunks stored in the local buffer)". Lingli,
> have I got your point?
>  + 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;” --> done
>  + 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? --> done
>  + 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)” --> done
> + 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.”  --> I re-phrased "simple peers, whose behavior has already been
> presented, and repeater nodes, that implement the same peer protocol as
> simple peers and in addition are high-bandwidth peers and are able to
> forward any sub-stream. In such a way repeater nodes serve as bandwidth
> multiplier".  Lingli, have I got your point?
>  + 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”  --> done
>  + 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. --> done
> + 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.” --> Lingli, I think your comment after the subsequent one is
> correct. So I completely removed this part. See my observation later on. Do
> you agree?
> + 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? Lingli, I don't
> think this is the case, because Bit Torrent is a P2P file sharing system
> and I have the impression that a section devoted to a P2P file sharing
> system could appear somehow out of scope. In addition, every time Bit
> Torrent is cited, we always tried to provide the necessary background info.
> Does it make sense?
> + 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. --> Lingli, the main problem here is
> that such a level of detail is often not available for all the
> applications. Regarding this point I also added the following statement in
> "Introduction" section "In addition, the provided descriptions may
> sometimes appear inhomogeneous from the detail level point of view, but
> this always depends on the amount of available information at writing time.".
>  So the only solution seems to me to remove the reference to the security
> mechanisms. The peer selection algorithm is full part of the peer protocol
> in my opinion and it has to be kept. But i would like to hear from you.
> + 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.”? -->
> Duan, if I remember correctly, you provided this part. Can you please
> explain?
>  + 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.”
> --> done
> + 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.  --> Lingli, this comment
> is not completely clear for me. Probably you meant New Coolstreaming. If
> so, New Coolstreaming may be regarded as hybrid, because on the one side
> you have an overlay mesh, on the other side you have as many trees as
> substreams. I also added the following statement "Hence, the overall
> overlay topology is mesh-based, but it is also possible to identify as many
> overlay trees as sub-streams.". Is it clearer now?
>
>
>  Please, let me know.
>
>  Regards
>  Francesca
>
>   From: duan shihui <[e-mail]>
> Date: Monday, December 2, 2013 5:26 PM
> To: "[e-mail]" <[e-mail]>
>
> Subject: Re: [ppsp] WGLC for the survey draft
>
>    Rachel, *Roni Even* and Lingli have given some good comments.
>  There are some errors in the survey draft which must be fixed.
>  when we written the survey draft, the RFC6972 is still in the draft
> status. Now we can refer to RFC6972 for some definitions.
>  I will consider carefully some comments from Lingli and give the reply
> in the subsequent mail.
>



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