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

["Narayanan, Vidya" <[e-mail]>]

Hi Martin,
Given that Lisa is looking for solutions, I almost wish I have a solution thought out :) But, I don't.  At the moment, I'm just saying that ALTO should be beyond *only* dealing with information from service providers.  Peer selection is absolutely beyond just catering to ISP interests; peers have a vested interest in it - that said, information that peers are willing to share towards this is very valuable.  We need to have interoperable ways of making that available and I do think this fits nicely with the ALTO objectives - going back to the root of the objectives, it is about peer selection and not just about ISP network utilization interests.

Just to be clear, I am not downplaying the importance of ISP network utilization aspects - it is one component of the puzzle and there are others we need to consider along with it for a more complete picture.

Thanks,
Vidya

> -----Original Message-----
> From: Martin Stiemerling [mailto:[e-mail]]
> Sent: Monday, October 13, 2008 8:03 AM
> To: Narayanan, Vidya; Vijay K. Gurbani
> Cc: [e-mail]; IESG IESG; [e-mail]
> Subject: RE: [p2pi] WG Review: Application-Layer Traffic
> Optimization (alto)
>
> Hi Vidja, all,
>
> I believe that the charter is narrow and broad enough to
> cover the topic of ALTO, i.e., the charter is not limiting
> the solution space.
>
> However, when reading your comments, it sounds that you have
> a very specific solution in mind which is probably not
> covered by the current charter.
>
> [...]
>
> > >
> > > > Overall, I think we should work with the notion of an ALTO
> > "service"
> > > >  rather than specifically an ALTO "server".
> > >
> > > Great.  I believe that is exactly what the charter does;  the
> > > charter talks in terms of an "ALTO service" at many places
> > > (pedantically speaking, the term "ALTO service" occurs
> eight times
> > > and the term "ALTO server" occurs six.)  The ALTO "server"
> > > mentioned in the charter refers to the *host* the client finally
> > > queries (calling it a "peer" is ambiguous; if you have a specific
> > > term to use here instead of "server", please do let us know.)
> > >
> >
> > When we consider ALTO as a distributed service, there may not
> > necessarily be "a" host that specifically resolves the ALTO queries.
> > For instance, consider the case where ALTO is a service
> offered in an
> > overlay.  There may be peers publishing information about
> themselves
> > on the overlay and other peers looking up such information.
>  These are
> > not necessarily client-server style communications.  In
> fact, all that
> > is important in this context is that the overlay acts as a
> rendezvous
> > for sharing such information.  Now, of course, that is one
> possible model.
>
> You probably have a publish/subscribe system in mind for p2p overlays.
> I assume this is not in scope of ALTO.
>
> > But, in order to allow for that and other models, I do want the
> > charter to keep the focus on the service and not on a server.
>
> Is the IETF anyhow standardizing services? I don't see this.
>
> [...]
>
>
> > >
> > > We have had discussions on the mailing list about this already.
> > > Some people felt that providing uplink bandwidth would
> not be a good
> > > idea for various reasons running from privacy concerns to peers
> > > skewing traffic in favor of a high uplink bandwidth.
> > > Others felt that even if a peers uplink bandwidth was not
> provided,
> > > it could calculated nonetheless by other peers.
> > > That is, there are degrees of disagreement here and consequently,
> > > including a contentious point in the charter would be counter-
> > > productive.
> > >
> >
> > I'm afraid that would be a mistake.  It actually doesn't
> matter if we
>
> I'm afraid that carrying up/downlink capacity of the peer's
> local link is a complete waste of resource, as this is not
> indicating something. For instance, a peer may have a
> relatively huge uplink but on a shared medium, i.e., a medium
> which might be shared by hundreds of other hosts/traffic.
> So what does this information express?
>
> > don't agree today on the exact types of information that
> can be shared.
> > It is important that we have a protocol that allows peers
> to publish
> > ALTO related information.  Having this protocol be extensible would
> > allow for any type of information to be carried in it.  So,
> I strongly
>
> The question is, whether the roots of ALTO are actually
> intended to carry any type of information? The main idea is
> to carry information to optimize traffic, e.g., decreasing
> cross ISP traffic.
>
> > believe we don't need a recharter to consider any
> information types -
> > in fact, I'd be okay if this effort only took on the
> protocol and if
> > all information types were to be registered through other
> means.  That
> > said, I'm not against taking on some subset of those types
> - I don't
> > believe that should be the core focus of this work though.
> >
> > > > - The ability to register information types with IANA
> and extend
> > > > these.
> > >
> > > Having a IANA registry for the information type carried in the
> > > protocol is certainly a possibility the charter does not
> rule out,
> > > no?
> > >
> >
> > Well, it is a bit hard to say what the charter does not rule out -
> > typically we try and do what the charter says we should do.
>  However,
> > before we get to the registry, we need to agree on the protocol
> > components.  In my view, there are two such components -
> the publish
> > protocol mentioned above and the request/response protocol
> (actually,
> > more generically, a lookup protocol) mentioned below.
>
> It is good to see your ideas but doesn't this go beyond a
> charter discussion, as your are discussing a solution?
>
> This comes back to my initial comment about discussing a
> specific solution, and we haven't yet reached the times to
> discuss a solution - at least not here.
>
>   Martin
>
>
> [e-mail]
>
> NEC Laboratories Europe - Network Research Division NEC
> Europe Limited | Registered Office: NEC House, 1 Victoria
> Road, London W3 6BL | Registered in England 2832014
>
_______________________________________________
p2pi mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/p2pi