Recently, draft-wydrych-alto-paths-00 &
draft-gao-alto-routing-state-abstraction-00 have proposed extending ALTO
with path-based costs. I'm going to outline a considerably simpler way to
accomplish the same goal. I would like all of you -- and especially the
authors of those drafts! -- to let me know what those extensions provide
that this doesn't.
The Problem:
The ALTO cost model assumes costs depend only on the source & destination
addresses. But modern networks route on other attributes (protocol,
dest-port, diffserv, etc) as well as destination address. The result is
that the cost for downloading a file may depend on the protocol: rtp,
tcp/port80, tcp/other-port, etc.
What's worse, those protocol-dependent costs might not "track." That is,
if you stream a video via rtp, ServerA might be faster than ServerB, but
if you download it via http, ServerB might be faster.
The current ALTO cost model cannot convey those distinctions.
Observation #1:
While paths may be the cause of the cost differences, ALTO clients -- end
user applications -- do not care about the paths their packets take. ALTO
clients just care about the end-to-end costs.
Feel free to describe a use-case that contradicts this claim!
I realize that multi-flow clients need to know about paths, to determine
how much the routes to several different endpoints overlap. But those are
not the clients I am talking about here.
Observation #2:
Clients who are concerned about protocol-dependent costs are only
interested a small number of different protocol/port/etc combinations.
That is, an ALTO client might be interested in the costs for downloading
via rtp vs http. But that is all; the client does not care about the costs
for other protocols & ports.
Again, feel free to point out a use-case that contradicts that claim.
My Proposal:
Instead of introducing a path abstraction, suppose we extend the cost-type
with parameters that describe the packet type, such as protocol, src-port,
dst-port & diffserv. Then a client request for a Filtered Cost Map might
look like this:
{
"cost-type" : {
"cost-metric" : "routingcost",
"cost-mode" : "numerical",
"src-port" : 80,
³protocol" : 6
},
"pids" : {
"srcs" : [ "PID1", "PID2", "PID3" ],
"dsts" : [ "PID1" ]
}
}
The ALTO server returns the numerical routing costs from the srcs to the
dsts, for packets with the indicated port & protocol. If there is no
special route for that packet flavor, the ALTO server simply returns the
general routingcost for the src & dst.
If a client wants costs for a small number of different protocols, the
client can use the multi-cost extension, draft-ietf-alto-multi-cost-00.
My Question:
What do the proposed path-based cost extensions provide that this does not?
- Wendy Roome
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
