Subject: [ppsp] WGLC for the survey draft

From: yunfei zhang <[email-masked]>
Date: Tue, 26 Nov 2013 21:04:30 +0800

Hi all,
    According to the consensus of last IETF, we'll start a second round of
WGLC for the survey draft:
http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/
    The WGLC will last for 2 weeks before submitting for next step of
standardization.
     Your review are highly appreciated. Please note that your comments and
suggestions are very important for the forming of the RFC as well as the
development of the WG. Thanks.

BR
Yunfei
---------- Forwarded message ----------
From: Zongning <[email-masked]>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "[email-masked]" <[email-masked]>

Hi, Folks,

Sorry for the belated minutes and thanks Roni for taking the notes. Please
see below and let us know any corrects needed.

===========================================================

PPSP Session@IETF 88

Plaza C,Tuesday Afternoon Session III, Nov 5, 2013

16:10 Agenda bashing (Chairs, 5 minutes)

No comments

16:15 Status of the WG (Chairs, 10 minutes)

1)  Peer draft – more review needed, especially on security and
encoding perspectives.

2)  Tracker base draft – need author team to progress the draft
faster, more calls are needed.

3）Survey draft – need 2nd WGLC before submitting to IESG.

16:25 Peer Protocol (Arno remotely,50 minutes), draft-ietf-ppsp-peer-protocol-08

1)  New revision has addressed all comments from AD review.

2)  Some comments from Roni need to be addressed, e.g. if peer
protocol need to define how to do NAT traversal. To be discussed on
the list.

3)  Chunk size issue from Yunfei?

4)  Chunk addressing issue – negotiation is better.

Lingli: in the latest version, the part for online translation between
communicating peers using different chunk addressing schemes are removed.
Why?

A: It is too complicated and not necessary.

17:15 Tracker Protocol (Rui remotely, 50 minutes),
draft-ietf-ppsp-base-tracker-protocol-02

1)  In the draft, still XML format in main body. Need to move XML
example to appendix with more references.

Yunfei: The new version doesn’t reflect the consensus made in the last
meeting, which is to move the encoding issues to the appendix while keep
the main body to just define messages. Currently the messages are still
text based. Is there any consideration on the situation where different
encodings are used? E.g., some peers use text encoding while others use
binary.

Lingli: There is different understanding between Rui and the other
co-authors. By binary encoding, Rui thinks it’s the binary encoding of the
XML, while others think it’s the binary encoding of the tracker protocol.
There are standards from ISO for binary encoding of XML, which is EXI.

Yunfei: But EXI can’t do the translation between binary encoding of the
messages to XML of the messages.

Lingli: Websocket has similar mechanisms to do this kind of translation. We
can reference it. I can help with the new version.

18:05 Efficient Chunk Availability Compression (Lingli,20 minutes),
draft-deng-ppsp-bfbitmap-03

Arno: in reality, streaming downloading happens sequentially, hence
scope-based schemes works well.

A: in VoD cases, user behavior can interrupt the sequential viewing
pattern. And even in live streaming case, because the concurrently
peer-to-peer downloading pattern, out-of-order chunk transmission is
inevitable.

Dave: what is the objective of introducing BF scheme?

A: the motive is elaborated in the last meeting’s presentation. There
is an comparison of the worst case performance of different bitmap
compression schemes in terms of various bitmap relevant operations in
PPSP.

Arno: in peer protocol, peers don’t share bitmaps, only chunk ranges
updates are exchanged. Peer protocol doesn’t need bitmap compression.

A: ranges or updates are special forms of compression. BF scheme can
be introduced into peer protocol as a new chunk addressing method.

open issue 1 – looks like the proposed option is better no need to translation

Open issue 2 – looks like it is helpful to include content scope into
requests, but not to the responses.

No adoption at the moment. Need more mailing list discussion and
offline with the tracker protocol author.

Rachel: in extended tracker protocol, the content scope information is
already incorporated in the requests. But if we incorporate the same
information into the responses, it would be duplicated with the
subsequent peer information handshaking.

Ning: Would it be possible to increase neighborhood establishment by
always including SEEDER peers in response?

A: I think it make sense to do so to ensure FIND always hit, as long
as the specific content range in need is incorporated in corresponding
requests.

18:25 Conclusion and next step (Chairs, 10 minutes)

Peer draft needs more review. Tracker base draft needs call between
co-authors to progress the draft faster. 2nd WGLC on survey draft
starts soon.

18:35 End

===================================================

Thanks,

-Yunfei & Ning.

_______________________________________________
ppsp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Thu, 28 Nov 2013 06:25:39 +0000

Hi,

I have reviewed this drafts, and have following comments:

1.       The description in the last paragraph of Section 1 is inconsistent with the organization of chapters . This should be fixed.

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

3.       Section 1 typo: “we always try to identity tracker and peer protocols” should be “we always try to identify tracker and peer protocols”

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

Best regards,
Rachel

From: ppsp [mailto:[email-masked]] On Behalf Of yunfei zhang
Sent: Tuesday, November 26, 2013 9:05 PM
To: [email-masked]
Subject: [ppsp] WGLC for the survey draft

Hi all,
    According to the consensus of last IETF, we'll start a second round of WGLC for the survey draft:
http://datatracker.ietf.org/doc/draft-ietf-ppsp-survey/
    The WGLC will last for 2 weeks before submitting for next step of standardization.
     Your review are highly appreciated. Please note that your comments and suggestions are very important for the forming of the RFC as well as the development of the WG. Thanks.

BR
Yunfei
---------- Forwarded message ----------
From: Zongning <[email-masked]<mailto:[email-masked]>>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Hi, Folks,

Sorry for the belated minutes and thanks Roni for taking the notes. Please see below and let us know any corrects needed.

No comments

1)  Peer draft – more review needed, especially on security and encoding perspectives.

2)  Tracker base draft – need author team to progress the draft faster, more calls are needed.

2)  Some comments from Roni need to be addressed, e.g. if peer protocol need to define how to do NAT traversal. To be discussed on the list.

3)  Chunk size issue from Yunfei?
4)  Chunk addressing issue – negotiation is better.
Lingli: in the latest version, the part for online translation between communicating peers using different chunk addressing schemes are removed. Why?
A: It is too complicated and not necessary.

17:15 Tracker Protocol (Rui remotely, 50 minutes), draft-ietf-ppsp-base-tracker-protocol-02

1)  In the draft, still XML format in main body. Need to move XML example to appendix with more references.
Yunfei: The new version doesn’t reflect the consensus made in the last meeting, which is to move the encoding issues to the appendix while keep the main body to just define messages. Currently the messages are still text based. Is there any consideration on the situation where different encodings are used? E.g., some peers use text encoding while others use binary.
Lingli: There is different understanding between Rui and the other co-authors. By binary encoding, Rui thinks it’s the binary encoding of the XML, while others think it’s the binary encoding of the tracker protocol. There are standards from ISO for binary encoding of XML, which is EXI.
Yunfei: But EXI can’t do the translation between binary encoding of the messages to XML of the messages.
Lingli: Websocket has similar mechanisms to do this kind of translation. We can reference it. I can help with the new version.

18:05 Efficient Chunk Availability Compression (Lingli,20 minutes), draft-deng-ppsp-bfbitmap-03

Arno: in reality, streaming downloading happens sequentially, hence scope-based schemes works well.

A: in VoD cases, user behavior can interrupt the sequential viewing pattern. And even in live streaming case, because the concurrently peer-to-peer downloading pattern, out-of-order chunk transmission is inevitable.

A: the motive is elaborated in the last meeting’s presentation. There is an comparison of the worst case performance of different bitmap compression schemes in terms of various bitmap relevant operations in PPSP.

Arno: in peer protocol, peers don’t share bitmaps, only chunk ranges updates are exchanged. Peer protocol doesn’t need bitmap compression.

A: ranges or updates are special forms of compression. BF scheme can be introduced into peer protocol as a new chunk addressing method.

Open issue 2 – looks like it is helpful to include content scope into requests, but not to the responses.

No adoption at the moment. Need more mailing list discussion and offline with the tracker protocol author.

Rachel: in extended tracker protocol, the content scope information is already incorporated in the requests. But if we incorporate the same information into the responses, it would be duplicated with the subsequent peer information handshaking.

Ning: Would it be possible to increase neighborhood establishment by always including SEEDER peers in response?

A: I think it make sense to do so to ensure FIND always hit, as long as the specific content range in need is incorporated in corresponding requests.

Peer draft needs more review. Tracker base draft needs call between co-authors to progress the draft faster. 2nd WGLC on survey draft starts soon.

18:35 End

Thanks,

-Yunfei & Ning.

_______________________________________________
ppsp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ppsp

---

From: "Roni Even" <[email-masked]>
Date: Thu, 28 Nov 2013 16:16:38 +0200

Hi,

I read the document. It looks good I just have some editorial comments

Some nits

1.       Figure 1 “traker” should be “tracker”

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

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

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

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

6.       In section 3.1.6 when first using CDN expand to Content Delivery
Network (CDN)

Roni Even

From: ppsp [mailto:[email-masked]] On Behalf Of yunfei zhang
Sent: 26 November, 2013 3:05 PM
To: [email-masked]
Subject: [ppsp] WGLC for the survey draft

Hi all,

BR
Yunfei

---------- Forwarded message ----------
From: Zongning <[email-masked]>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "[email-masked]" <[email-masked]>

Hi, Folks,

PPSP Session@IETF 88

16:15 Status of the WG (Chairs, 10 minutes)
1)  Peer draft - more review needed, especially on security and encoding
perspectives.
2)  Tracker base draft - need author team to progress the draft faster, more
calls are needed.
3）Survey draft - need 2nd WGLC before submitting to IESG.

16:25 Peer Protocol (Arno remotely,50 minutes),
draft-ietf-ppsp-peer-protocol-08
1)  New revision has addressed all comments from AD review.
2)  Some comments from Roni need to be addressed, e.g. if peer protocol need
to define how to do NAT traversal. To be discussed on the list.
3)  Chunk size issue from Yunfei?

4)  Chunk addressing issue - negotiation is better.

17:15 Tracker Protocol (Rui remotely, 50 minutes),
draft-ietf-ppsp-base-tracker-protocol-02
1)  In the draft, still XML format in main body. Need to move XML example to
appendix with more references.

Yunfei: The new version doesn’t reflect the consensus made in the last
meeting, which is to move the encoding issues to the appendix while keep the
main body to just define messages. Currently the messages are still text
based. Is there any consideration on the situation where different encodings
are used? E.g., some peers use text encoding while others use binary.

18:05 Efficient Chunk Availability Compression (Lingli,20 minutes),
draft-deng-ppsp-bfbitmap-03
Arno: in reality, streaming downloading happens sequentially, hence
scope-based schemes works well.
A: in VoD cases, user behavior can interrupt the sequential viewing pattern.
And even in live streaming case, because the concurrently peer-to-peer
downloading pattern, out-of-order chunk transmission is inevitable.
Dave: what is the objective of introducing BF scheme?
A: the motive is elaborated in the last meeting’s presentation. There is an
comparison of the worst case performance of different bitmap compression
schemes in terms of various bitmap relevant operations in PPSP.
Arno: in peer protocol, peers don’t share bitmaps, only chunk ranges
updates are exchanged. Peer protocol doesn’t need bitmap compression.
A: ranges or updates are special forms of compression. BF scheme can be
introduced into peer protocol as a new chunk addressing method.

open issue 1 - looks like the proposed option is better no need to
translation
Open issue 2 - looks like it is helpful to include content scope into
requests, but not to the responses.
No adoption at the moment. Need more mailing list discussion and offline
with the tracker protocol author.

Rachel: in extended tracker protocol, the content scope information is
already incorporated in the requests. But if we incorporate the same
information into the responses, it would be duplicated with the subsequent
peer information handshaking.
Ning: Would it be possible to increase neighborhood establishment by always
including SEEDER peers in response?
A: I think it make sense to do so to ensure FIND always hit, as long as the
specific content range in need is incorporated in corresponding requests.

18:25 Conclusion and next step (Chairs, 10 minutes)
Peer draft needs more review. Tracker base draft needs call between
co-authors to progress the draft faster. 2nd WGLC on survey draft starts
soon.

18:35 End

Thanks,

-Yunfei & Ning.

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Fri, 29 Nov 2013 01:07:12 +0000

One more comment:

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

Best regards,
Rachel

From: ppsp [mailto:[email-masked]] On Behalf Of Huangyihong (Rachel)
Sent: Thursday, November 28, 2013 2:26 PM
To: yunfei zhang; [email-masked]
Subject: Re: [ppsp] WGLC for the survey draft

Hi,

Best regards,
Rachel

Hi all,

BR
Yunfei
---------- Forwarded message ----------
From: Zongning <[email-masked]<mailto:[email-masked]>>
Date: 2013/11/25
Subject: [ppsp] Meeting minutes
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Hi, Folks,

No comments

18:35 End

Thanks,

-Yunfei & Ning.