Wendy, A few thoughts.
With respect to Observation #1 a client *does* care about the congestion state of a single path in a non-multipath scenario. It is for this very reason in the mobile world that the phones 'Connection Optimizers' and radio access network packet schedules begin looking at other radio access technology or channel alternatives. With respect to Observation #2 is correct if we consider 'small number' say less than 6. I know that is a nit but it I find it to be all about perspective. I like your proposal but it is often not enough to consider the top protocol and you need to look at the stack itself. For instance, http/tcp http/mptcp and http/dash (which can include eMBMS on a LTE network) http/quic yield wildly different results in terms of uplink performance and, in turn downlink performance at high speeds due to the ACK speeds and windowing. Finally, the path extensions make sense. I liken PID to PID metrics at the measurements of one link so we can understand the cost of egressing a PID and entering another. This is no different that L2/3 QoS. However, the next question is what is the cost of entering PID A and traversing internal links to then make the connection to PID B. It is not the cost of PID A to B over a L2/L3 link. How would we represent the difference? We had the same issue 20 years ago for QoS in general. Layer 2 tech does well for QoS across Layer 2 but did not give priority to QoS within the router itself - hence DiffServ. I consider Cost maps the Layer 2 of metrics but we are still missing the internal one. If the cost of transiting a PID to any other PID is constant than Cost (PIDA => PIDA) = X is sufficient. If not then we have a representation issue that ALTO does not currently address. Finally there is a question of hierarchical aggregation when presenting a metric value. How would we measure the Cost from PID A to PID B when there are 3 endpoints in each PID fully meshed to each other but the links have slightly different measurements due to our ability to precisely measure the metric which may lead to several significant digits. Which path or paths represents the cost in Costmap? How did this get noted as the summary? How can this be tracked when an Operator needs to understand how the server came to this value? I am not saying path representation answer all or any of these questions but I do understand the value it can provide in terms of giving further information. Also, as far as metrics go packet-count, flow-count and ECN packets observed over a time window are very useful to operators and may be useful in ALTO. It was such a driver that changes were made to Diameter to address this - https://tools.ietf.org/html/draft-ietf-dime-congestion-flow-attributes-02 Lyle -----Original Message----- From: alto [mailto:[email protected]] On Behalf Of Wendy Roome Sent: Tuesday, July 28, 2015 8:33 AM To: IETF ALTO <[email protected]> Subject: [alto] Parameterized ALTO cost-types 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 ________________________________ This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message. _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
