ietf
[Top] [All Lists]

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

2008-10-14 20:10:32
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:Stiemerling(_at_)nw(_dot_)neclab(_dot_)eu]
Sent: Monday, October 13, 2008 8:03 AM
To: Narayanan, Vidya; Vijay K. Gurbani
Cc: p2pi(_at_)ietf(_dot_)org; IESG IESG; ietf(_at_)ietf(_dot_)org
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


stiemerling(_at_)nw(_dot_)neclab(_dot_)eu

NEC Laboratories Europe - Network Research Division NEC
Europe Limited | Registered Office: NEC House, 1 Victoria
Road, London W3 6BL | Registered in England 2832014

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>