I don't think the "default cost" idea is worth it.
The only advantage I see is sending fewer bytes over the wire when a lot
of the costs are exactly the same. That strikes me as very unlikely.
Outside of the artificial cost maps we invented for our interop tests, of
course!
And if a server does use a default cost, then the server cannot indicate
"unknown cost" for a src/dest pair.
- Wendy Roome
>Date: Mon, 25 Mar 2013 10:53:49 +0100
>From: Sebastian Kiesel <[email protected]>
>Subject: Re: [alto] Cost map: undefined vs. default value
>
>Ben, all,
>
>On Mon, Mar 25, 2013 at 09:06:18AM +0000, Ben Niven-Jenkins wrote:
>>Sebastian,
>>On 25 Mar 2013, at 08:31, Sebastian Kiesel wrote:
>>> Dear all,
>>>
>>> draft-ietf-alto-protocol-14, section 9.1.2.5. says: "An ALTO Server MAY
>>> omit entries for which a Path Cost is not defined (e.g., both the
>>>Source
>>> and Destination PIDs contain addresses outside of the Network
>>>Provider's
>>> administrative domain)."
>>>
>>> I think it would be beneficial to have an (optional) method of
>>>specifying
>>> a default value in the header of the map.
>>Are you suggesting the default cost replace the unknown cost semantic
>>or that we keep the unknown cost semantic and add an additional
>>default cost semantic?
>
>Both options would work for me as I personally do not see much use of
>the "undefined" semantic. On the other hand, adding the "cost-default"
>as an optional feature seems less disruptive wrt. existing
>implementations and then we could support both the "undefined" and the
>"default" semantics, so I think the proposal is: add it as an option,
>i.e., if "cost-default" is present all omitted entries in the cost map
>are assigned this value, otherwise they are undefined.
>
>Thanks
>Sebastian
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
