[ppsp] 答复: Comments on draft-ietf-ppsp-reqs-03

[Ning Zong <[e-mail]>]

Hi, Arno,

Please see inline.

-----邮件原件-----
发件人: [e-mail] [mailto:[e-mail]] 代表 Arno
Bakker
发送时间: 2011年8月4日 15:24
收件人: [e-mail]
主题: [ppsp] Comments on draft-ietf-ppsp-reqs-03

Hi all

here are my comments on v3 of the requirements document:

* PPSP.REQ-8: I propose to rephrase this such that the protocols MUST
be able to provide a specified QoS, as Johan Pouwelse also suggested,
rather than requiring a mechanism to convey the QoS.

[ZN]: I agree with your proposal.

* PPSP.TP.REQ-6: IMHO we should allow for two types of trackers: simple
and smart. For simple trackers it will be sufficient to require that
peers report (e.g. periodically) to the tracker to show they still are
in the swarm (so the tracker will not give out addresses of peers that
left), without information about what chunks they have. Requirements
for simple trackers are mandatory. Smart trackers may use extra
information from peers to steer peer selection based on network
and peer conditions. Smart trackers would be optional in PPSP, and
peers would only need to send the extra required info, such as their
chunk availability, when a tracker is smart and needs it.

[ZN]: I agree with your proposal.

If there is a need for trackers to be used as monitoring facilities
by service operators, we should define mandatory information that a peer
should send to the trackers for this purpose (e.g. its progress).
In other words, let's define minimal tracker functionality and allow
for extensions.

* p.9  The part about CHUNK AVAILABILITY DIGEST I propose be rewritten
into a requirement that chunk availability MUST be as expressed as
compactly as possible.

[ZN]: I agree with your proposal.

* p.9  States that "The data transport mechanism and transmission
control are out of scope". I propose to rephrase this to fit with the
PPSP charter that says "The first task for this WG will be to decide
which signaling and media transfer protocols will be used. The WG will
consider existing protocols and, if needed, identify potential
extensions to these protocols." I.e. it puts extensions of transmission
protocols into the PPSP WG's scope.

[ZN]: OK.

* PPSP.PP.REQ-1+2+4: I propose to allow more explicitly for a
push-based model, where peers advocate their own chunk availability
proactively, and state that the peer protocol MUST implement either
pull-based, push-based or both.

[ZN]: We have paragraph on page 10 to describe the two modes of pull & push
information among peers.
And I don't think it is necessary to state these modes in a formal
requirement.

PPSP.PP.REQ-3: I propose to rephrase this to something like "Peers MAY
use the streaming content availability request message to solicit an
additional list of peers to that received from the tracker - with the
same swarm ID. The resulting reply message MUST contain only the
addresses of peers that have explicitly indicated they are part of the
swarm, verifiable by the receiver. This means, for example, that the
addresses are in some sort of swarm-membership certificates self-signed
with a peer's public key. This explicit membership requirement also
holds for any push-based peer-address exchanges in the protocol.

[ZN] I agree with your proposal.

Peers MUST not be allowed to send a list of arbitrary IP
addresses+ports. Otherwise, if they are malicious they can trick
other peers into connecting to arbirary hosts. So this hearsay
mechanism would provide a DoS attack vector."

* p. 10: Paragraph on CHUNK AVAILABILITY may be removed if compact
representation is made a requirement, see above.

* PPSP.PP.REQ-6: Is phrased ambiguously at present IMHO. When read as
"The peers MUST implement the peer protocol for chunk
[availability] requests and responses among the peers before the
streaming content is transmitted." it seems self-evident, one
cannot request a chunk if one doesn't know what chunks the requestee
has. Hence the requirement seems superfluous.

[ZN] This is not about chunk availability, but requesting the chunk itself.
For example, peer A send this message to peer B to request a specific chunk,
as well as its streaming capability information.
This message is more like a session negotiation/description message (e.g.
RTSP, SIP, etc).

* PPSP.SEC.REQ-9: I propose to remove the part that requires
reporting receiving bad content to the tracker. Reporting to the
tracker would allow for false reporting by malicious peers and
arbitrating these reports is very complex.

[ZN] Yunfei and Lingli Deng, what's your opinions on this?

Typos/phrasing:

p. 4  "instance messaging" -> "instant messaging"
       "one to one", "one to many" -> "one-to-one", "one-to-many"

p. 5  "request other peers for content" -> "request content from other 
peers"

p. 7  "can refer the ID for the peer" -> "can refer to the peer by ID"

p. 7  "Especially In provisioning" -> "Especially in provisioning"

[ZN] Thanks for identifying them. Good reading!

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