Subject: Re: [alto] Cost map: undefined vs. default value

From: Wendy Roome <[email-masked]>
Date: Mon, 25 Mar 2013 16:22:21 -0400

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-masked]>
>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

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 25 Mar 2013 22:27:34 +0100

Wendy,

how would you encode a cost map where most of the entries are
"I don't know", some are "you should try these" and some are 
"better avoid this PID"?  Reducing the number of PIDs so that
I have only one (or very few) "I don't know"-PIDs is not an
option because I am planning other cost maps with many details, too.

Thanks
Sebastian

On Mon, Mar 25, 2013 at 04:22:21PM -0400, Wendy Roome wrote:
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 25 Mar 2013 21:43:42 +0000

Sebastian,

> option because I am planning other cost maps with many details, too.

What's the driver behind allowing a default cost? Is it to reduce bytes on the wire or simplify the server (or client) processing in some way, or something else?

If the driver is saving bytes on the wire, I don;t think it's worth it, just either pre-gzip your maps or use Content-Encoding: gzip at the HTTP layer.

If it's simplifying the server/client processing, I'm not sure it makes much difference either.

If the driver is something else then I've missed what that is.

Ben

---

From: Sebastian Kiesel <[email-masked]>
Date: Mon, 25 Mar 2013 23:25:21 +0100

Ben,

On Mon, Mar 25, 2013 at 09:43:42PM +0000, Ben Niven-Jenkins wrote:
> What's the driver behind allowing a default cost? Is it to reduce
> bytes on the wire or simplify the server (or client) processing in
> some way, or something else?
> 
> If the driver is saving bytes on the wire, I don;t think it's worth
> it, just either pre-gzip your maps or use Content-Encoding: gzip at
> the HTTP layer.

I am thinking about the number of entries in my client-side hashes.
Bytes on the wire is another issue. gzip may reduce the size to some 25%
or something. Omitting those entries that have the default value would
save more with my map.

Sebastian

---

From: Wendy Roome <[email-masked]>
Date: Tue, 26 Mar 2013 09:18:57 -0400

Sebastian,

Here's how I would encode that, assuming you have other costs for which
you have known values:
* "You should try these": use 0 (or something much lower than the other
costs).
* "Better avoid": use 1e99 (json allows scientific notation).
* "I don't know": omit (I assume there are a lot of these).

You might also consider defining additional cost types, such as:

* avoid-these: 0 means "known to be okay", 1 means "known to be horrible",
missing means "unknown".

* best-picks: 0 means "excellent choice!", omitted means either "not as
good", "known to be bad", or just "unknown". Presumably this would be a
very sparse matrix.

	- Wendy

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 26 Mar 2013 14:34:18 +0000

Hi Wendy, Sebastian, Ben and all,

I see an interesting usage of a default value, so please let me know if I missed something. 
 
The protocol says Server MAY omit if the value is not defined, e.g. because it doesn't know the value maybe also because it does not want to expose it for this Cost Type on this src/dst pair. 
Likewise, both clients and servers would like to skip the burden of encoding/decoding src/dest pairs with no identified cost value. The Client can fill the information gaps on its own responsability. The proposed option that the ALTO Server provides guidance on the missing information with one default value assumes that:
 (i) the Server does not know the value but still wants to provide guidance and thus does provide a value which is DefaultValue.
(ii) the Client can use DefaultValue on this cost metric with no risk to misunderstand the ALTO network information and with the guarantee of having a reliable guidance.  
   
Question: is point (i) allways true or are there other possible reasons? e.g. are there possibly "pathological" lacks of cost values that would need to be encoded with specific values, say BogusValue?  

Actually DefaultValue may be useful in Cost Maps where it is very frequent and only a bunch say Maximum 10% of the s/d pairs have a different value, including BogusValue. In which case, it does not necessarily mean "ALTO Server does not know". 

In such a case, for the applicable Cost Map and Cost Type, the Client can catch DefaultValue and update only the s/d pairs with explicitely provided values. 

One may even figure that at some time or in some other circumstance, in a given Cost Map for a given Cost Type, the Cost value is unique = DefaultValue. The client then gets an empty map but the presence of a default value unambiguously indicates that information is provided.  

So when DefaultValue is "very frequent" (TBD) in a Cost Map, using it may optimize the transaction.

If not the Server just doesn't provide one. 

Sabine

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Wendy Roome
Envoyé : mardi 26 mars 2013 14:19
À : Sebastian Kiesel
Cc : [email-masked]
Objet : Re: [alto] Cost map: undefined vs. default value

Sebastian,

Here's how I would encode that, assuming you have other costs for which you have known values:
* "You should try these": use 0 (or something much lower than the other costs).
* "Better avoid": use 1e99 (json allows scientific notation).
* "I don't know": omit (I assume there are a lot of these).

* avoid-these: 0 means "known to be okay", 1 means "known to be horrible", missing means "unknown".

* best-picks: 0 means "excellent choice!", omitted means either "not as good", "known to be bad", or just "unknown". Presumably this would be a very sparse matrix.

	- Wendy

On 03/25/2013 17:27, "Sebastian Kiesel" <[email-masked]> wrote:

>Wendy,
>
>how would you encode a cost map where most of the entries are "I don't 
>know", some are "you should try these" and some are "better avoid this 
>PID"?  Reducing the number of PIDs so that I have only one (or very 
>few) "I don't know"-PIDs is not an option because I am planning other 
>cost maps with many details, too.
>
>Thanks
>Sebastian
>

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 28 Mar 2013 17:21:40 +0100

Wendy,

thanks.  So basically I can document the "default value" in the
definition of the cost and, e.g., define

routingcost-1000:

0  -> excellent choice!
...
10 -> good choice
..
999 -> should be slightly better than random

1000 explicityly indicated or entry omitted: If you pick hosts from
these PIDs, expect average results similar to those you would get
if you just picked hosts randomly without any ALTO guidance

1001 -> should be slightly worse than random
....
9999 -> better avoid
...
1e99 -> don't even think of it

This looks like a workaround to me, which works as long as the metric is
not tied to real units of measurement and as long as the
"better/worse-border" does not change too often.  It's OK for me if we
leave it as it is, but would it hurt someone if we add it as an option?

Sebastian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Mar 2013 14:17:46 -0500

[ As chair ]

On 03/28/2013 11:21 AM, Sebastian Kiesel wrote:
> definition of the cost and, e.g., define [...]

Sebastian: I suspect that we are better off not adding anything new to
the specification if we do not need to, especially if the option to be
added can be affected in an alternate (though more verbose) manner.

At this time, I think it is better to limit adding new options and and
concentrate on finishing the protocol specification.

That said, I trust the authors can provide a concrete example for
encoding different costs based on the conversation between you and
Wendy.  That is preferable to having a new, and perhaps normative
strength option that appears in the protocol document at this late a
stage.

Sorry to crack the proverbial whip, but let's try to wrap the protocol
document up as a first order of business.

I hope you understand.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Sebastian Kiesel <[email-masked]>
Date: Thu, 28 Mar 2013 20:44:23 +0100

Vijay, all,

sorry for starting or contributing to side tracks.  This all started
with the question whether the ALTO protocol is exceptionally vulnerable
to DoS attacks.  I don't think so.  Even though there is potential for
optimizations, the spec IMO can remain as it is.

Sebastian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 28 Mar 2013 15:15:05 -0500

On 03/28/2013 02:44 PM, Sebastian Kiesel wrote:
> Vijay, all,
>
> sorry for starting or contributing to side tracks.

Sebastian: No worries.  I think individually you all are contributing
to the benefit of the protocol, but collectively, it is time to
understand and document the design decisions so we can get the first
version of the protocol out the door.

This is not to say that we want to shortchange anything, but I
think as a group we need to keep in mind the principle of Occam's Razor,
if for nothing else than to guide us towards simplicity at this stage.
Change process is built into the IETF model, so I suspect we can
incrementally make the protocol better even after its issuance as an
initial RFC.

> This all started with the question whether the ALTO protocol is
> exceptionally vulnerable to DoS attacks.  I don't think so.  Even
> though there is potential for optimizations, the spec IMO can remain
> as it is.

Thanks for understanding.

Cheers,

- vijay