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