On 05/18/2012 15:00, "[email protected]" <[email protected]> wrote:

>On Mon, May 14, 2012 at 2:24 AM, Songhaibin <[email protected]>
>wrote:
>>Hi Rich,
>>
>>
>>
>>>-----Original Message-----
>>>From: [email protected] [mailto:[email protected]] On
>>>Behalf Of
>>>Richard Alimi
>>>Sent: Sunday, May 13, 2012 2:05 PM
>>>To: Songhaibin
>>>Cc: Enrico Marocco; [email protected]
>>>Subject: Re: [alto] WGLC: draft-ietf-alto-protocol-11
>>>
>>>On Mon, Apr 23, 2012 at 6:47 PM, Songhaibin <[email protected]>
>>>wrote:
>>>> In general, this draft is in good shape.
>>>>
>>>> One randomly caught problem, in Section 5.1.2.2, the ordinal mode
>>>introduction, it says this cost mode is a ranking from a particular
>>>source to
>a set of
>>>destinations. But in Section 5.2, the introduction of cost map
>>>structure, the
>cost
>>>mode "ordinal" can be applied to m*n entries in the cost map. So I
>>>suggest to
>>>modify the previous section 5.1.2.2 to make them consistent.
>>>>
>>>
>>>Thanks for catching that. In fact, the sentence "If the Cost Mode is
>>>'ordinal', the Path Cost of each communicating pair is relative to the
>>>m*n entries" can probably just be removed.
>>>
>>
>>I'm sorry that I have a different opinion here.
>
>No need to apologize :)
>
>[Haibin] I only pretended to be. :)
>
>>The "ordinal" cost to entries in a matrix makes sense to me. I prefer to
>modify the definition in 5.1.2.2, the ranking can be from multiple
>sources to
>multiple destinations. Or is there special reason to limit it to 1*n?
>>
>
>As an author/editor, I will say that the intent was for them to be
>relative to only the costs from the same source.  However, if the WG
>believes that should not be he case, then please do say so.
>
>To summarize the differences in semantics:
>(a) The interpretation that an ordinal cost is relative to all other
>entries in the cost map means a server could convey a policy like "I
>would rather you send traffic from s1 -> d1 instead of from s2 -> d2"
>(b) The interpretation that an ordinal cost is relative only to other
>ordinal costs from that same source means you can't specify that
>policy in an ordinal map.
>
>The original thought was that (b) makes the protocol a bit simpler to
>reason about and captures the major use cases for ordinal costs.
>However, it has slightly less expressive power when it comes to
>encoding policies.  It is certainly worth having the discussion as to
>which way we should go.
>
>Any other comments?
>
>[Haibin] I can give a use case where "option (a)" is meaningful. I think
>other people might give other use cases too. Assume that in CDN
>interconnection scenario, there are several surrogates from downstream CDN
>that can be injected delegate contents from upstream CDN, and at the same
>time there are a few surrogates in the upstream CDN that can provide the
>content. It is better to query the ALTO server do decide a path from a
>particuplar surrogate of upstream CDN to a surrogate of downstream CDN.
>The
>ordinal costs applied to a m*n entries can be used for this decision.

I always assumed "option a": ordinals are relative to all costs
in this response, not just the costs for the same source. Of course,
"option a" automatically satisfies "option b", so if a server is
willing to do (a), then the server is in compliance regardless of
what we decide.

        - Bill Roome


_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to