Subject: Re: [ppsp] ppsp Digest, Vol 63, Issue 2

From: duan shihui <[email-masked]>
Date: Wed, 4 Dec 2013 22:19:11 +0800

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

yes, it's right.
 the media is carried directly on the UDP and QQLive doesn't use RTP/RTCP
to carry the media. There is no RTP/RTCP in QQLive's protocols.

On Wed, Dec 4, 2013 at 7:08 PM, <[email-masked]> wrote:

> Send ppsp mailing list submissions to
>         [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://www.ietf.org/mailman/listinfo/ppsp
> or, via email, send a message with subject or body 'help' to
>         [email-masked]
>
> You can reach the person managing the list at
>         [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ppsp digest..."
>
>
> Today's Topics:
>
>    1. Re: WGLC for the survey draft (Francesca Lo Piccolo (flopicco))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 4 Dec 2013 11:08:33 +0000
> From: "Francesca Lo Piccolo (flopicco)" <[email-masked]>
> To: Zongning <[email-masked]>, duan <[email-masked]>,
>         "'yunfei zhang'" <[email-masked]>, Gu Yingjie
>         <[email-masked]>, lingli deng <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [ppsp] WGLC for the survey draft
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="windows-1252"
>
> 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 <[email-masked]<mailto:
> [email-masked]>>
> Date: Monday, December 2, 2013 5:26 PM
> To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>
> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.html
> >
> -------------- next part --------------
> An embedded and charset-unspecified text was scrubbed...
> Name: PPSP survey figures.txt
> URL: <
> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.txt
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: Ppsp survey-flp0.4.docx
> Type:
> application/vnd.openxmlformats-officedocument.wordprocessingml.document
> Size: 52889 bytes
> Desc: Ppsp survey-flp0.4.docx
> URL: <
> http://www.ietf.org/mail-archive/web/ppsp/attachments/20131204/71d03347/attachment.docx
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> ppsp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ppsp
>
>
> ------------------------------
>
> End of ppsp Digest, Vol 63, Issue 2
> ***********************************
>

---

From: lingli deng <[email-masked]>
Date: Thu, 5 Dec 2013 10:56:38 +0800

Hi Duan and Francesca,

Sorry for the confusion.
I do understand that QQlive does not use RTP/RTCP protocols.
But do we need to stress the fact here? It gives the impression that some
referring systems are using RTP/RTCP. Is it the case?
Otherwise, I would recommend simply removing "not RTP/RTCP" in the sentence.

BR
Lingli

2013/12/4 duan shihui <[email-masked]>

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

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