Re: [alto] Parameterized ALTO cost-types

[Wendy Roome <[e-mail]>]

Lyle,

Thanks for your comments. This is exactly the sort of discussion I hoped
to start. My comments in-line.

On 07/28/2015, 11:00, "Bertz, Lyle T [CTO]" <[e-mail]>
wrote:

>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.

Can the congestion state and other problems be represented just by
increased cost? Or does the client really need to know the details about
the congestion?

Also, does ³other radio access technology or channel alternatives² mean
that the client adjusts the wireless device¹s access point, channel, power
level, etc? I don¹t believe those fit into the current ALTO network model,
so we would need extensions to get those concepts into ALTO.

>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.

6 should be fine. I really meant ³small enough to be feasible with the
multi-cost extension².

>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.

Can those be represented as additional parameters on a cost-type, or would
that require a more fundamental change?

>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?

Yes, but I think you are assuming that links are always between PIDs. I
think it is more likely that the links between PIDs will involve non-PID
entities (Abstract Network Elements). Eg, paths might be PID1 => link1 =>
router1 => link2 => PID2, and PID3=>link3=>router1=>link4=>PID4. That is,
the paths from PID1=>PID2 and PID3=>PID4 share a common element, router.
Since the router doesn¹t have any user endpoints, there is no need for it
to be a PID.

>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.

In that case, should those 3 endpoints really be in the same PID? I always
thought an informal definition of a PID was a set of endpoints such the
cost between any two endpoints in the PID was significantly less than the
cost between either endpoint and all endpoints outside the PID.

>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

One more consideration: what about ECS? I think ECS is likely to be the
most popular ALTO service. After all, clients are really interested in
costs between endpoints; PIDs are just a necessary abstraction. The
parameterized cost-type model fits nicely into ECS. Unless I missed
something, I think path-based costs won¹t work with ECS.

Here is one additional concern I have with path-based costs. My
understanding is that ALTO clients are end-user applications, and they
cannot select paths directly. Instead, clients select the output interface
(if the device has more than one), port, protocol, etc. The OS & network
then select the path based on that. So path-based costs require an
additional mechanism to tell the client how the network maps flows to
paths. That is possible, of course, but I haven¹t seen a concrete example
yet.

Thanks again for you comments and for starting the discussion!

	- Wendy Roome