Re: [p2pi] WG Review: Application-Layer Traffic Optimization (alto)

[Yu-Shun Wang <[e-mail]>]

Hi Vidya,

Comments inline. (I've only preserved the points I have
comments on. Others are fine with me.)

Thanks,
yushun

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Narayanan, Vidya
> Sent: Wednesday, October 22, 2008 5:51 PM
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] 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

_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi