Hi Vidya,
Comments inline. (I've only preserved the points I have
comments on. Others are fine with me.)
Thanks,
yushun
-----Original Message-----
From: p2pi-bounces(_at_)ietf(_dot_)org
[mailto:p2pi-bounces(_at_)ietf(_dot_)org] On Behalf Of
Narayanan, Vidya
Sent: Wednesday, October 22, 2008 5:51 PM
-----Original Message-----
From: ietf-announce-bounces(_at_)ietf(_dot_)org
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On Behalf Of IESG
Secretary
Sent: Monday, October 06, 2008 1:36 PM
<...>
A significant part of the Internet traffic today is generated
by peer-to-peer (P2P) applications used for file sharing,
real-time communications, and live media streaming. P2P
applications exchange large amounts of data, often uploading
as much as downloading. In contrast to client/server
architectures, P2P applications often have a selection of
peers and must choose.
Add: "Peer selection is also a problem that has many different
applications in p2p systems - e.g., identifying the best peer to
download content from, identifying the best super peer to contact in a
system, using the best relay for NAT traversal, identifying the best
next hop for a query based on several criteria (e.g., quality,
reputation, semantic expertise, etc.), etc."
I actually think the proposed addition is somewhat redundant,
and could easily lead into ratholes on what are the metrics for
"best" and whether it is even possible to get the best. The
current charter tries to avoid that by saying "better-than-
random" selection gating mostly on getting better performance
and lowering the costs (as two examples). Also, what's the
"best" depends heavily on whom you ask. ISP's notions of "best"
may not align with those of the end users.
I am fine with the examples (targets for selections), but let's
try to avoid the debates on "best" again.
<...>
yet applications have at best incomplete
information about the topology of the network.
s/incomplete information about the topology of the network/incomplete
information to help the selection, e.g., topology of the network.
I'm neutral to this. I think the intention is to narrow the
initial scope to avoid confusion w/ TANA. The charter does
leave the door open to future re-chartering/work.
<...>
Other usages will be considered as extensions to the charter
once the work for the initial services has been completed.
I think we should delete the sentence above.
While it may seem redundant, I don't see anything wrong with
that. It just means we may have a narrow scope now, but we
will think about new extensions once we are done.
<...>
When the WG considers standardizing information that the ALTO
server could provide, the following criteria are important to
ensure real feasibility.
In the context of standardization, I don't think we should be trying to
evaluate the importance of any information. The idea for us should be
to standardize mechanisms to exchange peer selection related
information. The value of the actual information exchanged is very
contextual and not for general evaluation.
I read the list below somewhat differently. These are not for
relative importance of the information, but kind of a min
bar for what we want to do. While some may need re-wording,
the intent is fine, IMO.
- Can the ALTO service technically provide that information?
- Is the ALTO service willing to obtain and divulge that information?
- Is it information that a client will find useful?
- Can a client get that information without excessive privacy
concerns(e.g. by sending large lists of peers)?
- Is it information that a client cannot find easily some other way?
After these criteria are met, the generality of the data will
be considered for prioritizing standardization work, for
example the number of operators and clients that are likely
to be able to provide or use that particular data.
The above again gets into our evaluation of what is important based on
what we know today and is limiting.
This point does need some clarification and rewording.
Thanks,
yushun
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf