Wendy,
thanks for bringing this back to our attention again.
Some thoughts on that:
1. The size of the cost map does not necessarily scalewith the
square of the number of PIDs.
In particular when the ALTO server is operated by an access network
operator, I expect the cost matrix to be a very sparse matrix with
most of the values being some "I don't know" default value.
For example, being the operator of a (very small) access network in
Europe I can tell the cost and with some uncertanity also some
performance expecations for traffic from our network to various
destinations in the world, but I cannot tell much about about, say,
the connectivity from a given access network in the U.S. to one in
Japan - and neither me nor the users in our network will care too
much about that anyway ... In other words, I expect that an ALTO
server in an access network will basically deliver a vector (from
here to ...), leaving all other positions in the matrix to the
default value -> with our encoding the message size would scale
linear with the number of PIDs.
On the other hand, there may be "independent" ALTO servers in
the network, doing distributed meaurements and/or aggregation
of data retrieved from various access-network-local ALTO servers.
These might be able to deliver a dense matrix, i.e., one that
scales quadratically.
2. An ALTO server operator is free to define only a limited number
of PIDs, small enough that the cost map can be handled. The
opearator can decide on the tradeoff between accuracy and size,
and can adjust this as both available server and bandwith ressources
as well as network complexity change over time.
3. The cost map is a simple "tell me all you know" thing that can be
pre-computed and cached. If we abandon it, clients might be tempted
to ask multiple queries to gather as much information as possible,
each possibly causing server-side computations.
4. If we make the full cost map optional, what would be the
"MUST implement" part of the ALTO protocol? If all map, property,
and filtering services are optional this may harm interoperability.
So I tend say let's leave it mandatory but the opinion is not very strong.
Thanks
Sebastian
On Tue, Mar 19, 2013 at 10:39:03AM -0400, Wendy Roome wrote:
> Richard,
>
> You said,
>
> > We anticipate that most deployment cases will not generate huge maps and
> > hence it should be fine.
> >
> A year ago, when I realized that full cost maps can get very large, I asked
> the group how many PIDs they expected ALTO servers to provide. 10's, 100's,
> 1000's., .? No one answered that question. Just in case, I extended the
> Alcatel-Lucent ALTO server and client to handle several thousand PIDs, but
> it took some effort.
>
> Remember that protocols have a way of scaling up far past their designer's
> original expectations. For example, I'm old enough to remember when IPV4
> addresses seemed infinite. (I'm also old enough to have used keypunches and
> card decks and IBM System 360s, but that's another issue.)
>
> So think carefully about what would happen if the number of PIDs grows
> beyond our wildest dreams. Because it might!
>
> I certainly agree that the protocol should not define limits. But I think
> the protocol should allow an ALTO server to define & impose its own limits,
> and communicate those limits to clients. So here's my suggestion for how the
> ALTO protocol could support implementation-defined limits:
>
> 1) Make full cost-maps optional, instead of required.
> 2) For filtered cost map requests, add an optional IRD capability giving the
> server's limit on the number of source/destination pairs allowed per
> request.
> 3) Add a "Request Too Large" ALTO error code in case a client exceeds that
> limit.
>
> Comments, suggestions?
>
> - Wendy Roome
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
