[ppsp] 答复: Requirements comments: draft-ietf-ppsp-reqs-03

[Ning Zong <[e-mail]>]

Hi, Johan,

Thank you for your comments. I will do a new revision shortly.

BR,
Ning Zong

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Johan
Pouwelse
发送时间: 2011年7月29日 11:23
收件人: [e-mail]
主题: [ppsp] Requirements comments: draft-ietf-ppsp-reqs-03

Dear PPSP people,

The V03 requirements document reads as a mature piece of text and
seems nearly ready
to be finalized. Solid piece of work.

Listed below are some proposed minor textual changes. As small as they are
textual, in terms of technical impact they are larger. All issues
below where also raised and discussed publicly at PPSP IETF meeting
81 in Canada. Disclosure: in my capacity as scientific director of
P2P-next I'm responsible for one of the three submitted peer protocols
in PPSP. My comments are derived from our years of experience both
measuring and deploying P2P streaming systems. Key comments are
specifically targeted at enabling PPSP on low-power devices such as
smartphones, TV settop boxes and tablets. The text currently contains
some requirements which will add both needless complexity and battery
drain, according to our experience.

We very much welcome discussions regarding the remarks below.
Please respond, even if you agree. . .

In section 3 "Overview of PPSP", page 5. The definition of "report"
lists many examples, but omits a commonly used item which is
important for load balancing and fairness. Please consider adding
"total amount of bytes uploaded/downloaded to neighbour peers".

Still in Section 3 on page 6 regarding the very first sentence. Please
make only minimal required functionality mandatory (see low-power
remark above). For instance, by replacing existing text with:
" 1) Standard format/encoding of information between PPSP peers and
PPSP tracker. Some of this exchanged information may be explicitly
marked as optional. Exchanged information may include peer list, swarm
ID, chunk information, content availability, streaming status
including online time, link status, node capability and other
streaming parameters."

PPSP.REQ-7 on page 7. Please replace with the following outcome of
IETF meeting discussion.
"The tracker protocol is recommended to be carried over TCP. The peer
protocol is recommended to be carried over UDP in order to: facilitate
NAT traversal techniques such as STUN/ICE, minimize network socket usage
and facilitate congestion control algorithm for less-than-best-effort
'background' transmissions such as IETF LEDBAT."

PPSP.REQ-8 on page 7. This requirement is very restrictive for our design
space. Do we really desire explicit QoS communication or do we simply
require that the whole architecture support the QoS needed for streaming?
Please consider replacing this text with:
"The tracker and peer protocols MUST support acceptable QoS (e.g.
video quality, delay requirements)
for both on-demand and live streaming. In other words, the two
protocols together
must be fit-for-purpose. For instance, the protocols must be able to
provision sport
events with less than 1 minute of total end-to-end delay."

The second paragraph of PPSP.REQ-8 on page 7, beginning with:
"The quality for P2P live streaming system could be very bad.
Dependent from the"..
The purpose and meaning of this whole section could be clarified,
sharpened and made more demanding.
My hope is that this paragraph can be replaced with clear requirements
or that the entire paragraph is deleted {not fully happy with text
below, please help out if you're inspired}:
"PPSP.REQ-9: For both the live and on-demand streaming case the tracker and
peer
protocols MUST facilitate low startup delay (e.g. must not include
non-functional
Round Trip Time (RTT) delays).
PPSP.REQ-10: The tracker and peer protocol together MUST facilitate
low startup delay, low
channel/content switching time and minimal end-to-end delay for both
on-demand and
live streaming, even for very popular content. The tracker and peer
protocol do NOT include
the algorithm required for scalable streaming. However, the tracker
and peer protocol
SHALL NOT restrict or place limits on any such algorithm.

The first paragraph on page 8 ends with "The tracker protocol must
provide the possibility for the
request of alternative peer addresses, if the quality is not
sufficient for the user".
Why do we specify a solution or mechanism in the requirements, instead
of the survey?
Can we delete this entire paragraph or move it to the survey?

Section 4.3 "PPSP Peer Protocol Requirements" on page 9.
To prevent DoS problems it is vital that hearsay amongst peers is not
allowed.
Please revise PPSP.PP.REQ-1 with:
"The streaming content available request message MUST allow a peer to obtain
information about chunk availability of another peer. The chunk
information MUST at least
contain the chunk ID. This chunk availability information MUST NOT be passed
on
to other peer, unless validated (e.g. prevent hearsay and DoS)."

Again on page 9 a similar issue exists with the peer list.
Please revise PPSP.PP.REQ-3 by adding:
"This additional list of peers MUST only contain peers which have been
checked to be valid and online recently (e.g. prevent hearsay and
DoS)."

Concerning PPSP.PP.REQ-5 on page 10. Why is this required? This
restricts the protocol design space.
Please make this explicit information-based approach optional, as a
feedback based
approach utilising simple "failure detection" could perhaps yield
similar or superior results.

Greetings,
johan.
_______________________________________________
ppsp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ppsp