Subject: Re: [alto] alto Digest, Vol 32, Issue 18

From: Bill Roome <[email-masked]>
Date: Tue, 21 Jun 2011 10:22:06 -0400

>Date: Mon, 20 Jun 2011 09:53:28 -0700
>From: Richard Alimi <[email-masked]>
>
>On Fri, Jun 17, 2011 at 7:03 AM, Bill Roome <[email-masked]>
>wrote:
>>>>For that matter,
>>>>what happens if a client gives the same address twice in the same form?
>>>
>>>There's a more general question of what the server does if given an
>>>identical address (either in the same form or different forms)
>>>multiple times in a single list (and for that matter, multiple PIDs
>>>that are identical). ?It seems to me a reasonable server behavior
>>>would be to behave as if the address only appeared once. ?Objections?
>>>
>>>Thanks,
>>>Rich
>>
>>I just realized that's a non-issue. The costs are returned in a JSON
>>dictionary. That allows only one value per key. So if a client gives an
>>address or PID twice, the server can only return it once.
>>
>>BTW, I don't know how other have implemented a server, but the simple way
>>to handle a endpoint cost request is with
>>
>>? ?for each client source addr
>>? ? ? ?for each client destination addr
>>? ? ? ? ? ? lookup src=>dest cost
>>? ? ? ? ? ? insert cost into output JSON object
>>
>>With that, it's natural to use the client's string representation in the
>>response.
>>And it would take extra work to determine if the client had
>>given the same address in two different forms.
>
>Okay, so lets assume that there is a case where a single address has
>multiple textual representations (Martin had a doubt about that, but
>my reading of the RFC5952 looks to be the same as yours), we have a
>few options:
>(1) Make it so that there is only one possible textual representation.
>I'm not sure whats typical in the IETF for this, but this seems more
>like a debate to be had elsewhere in the IETF and not in the ALTO WG.
>Correct me if I'm wrong and we should actually be considering that.
>(2) Have the client deal with the complexity of: converting received
>addresses to bytes and converting addresses queried via its API to
>bytes.  I'll note that if you intend to write a client that does a
>lookup into the Network Map, you need to convert to bytes anyways to
>do longest-prefix-match.
>(3) Have the server deal with the complexity of: remembering the exact
>representation that was used in the query, do its internal processing,
>and serialize the response according to the representation that was
>used in the original query.  This would have to be done under possibly
>high load, and in order to scale to large request loads, this may be
>accomplished across multiple distributed servers.
>
>Given these tradeoffs, (2) sounds a lot better to me.  I'll note that
>I am sympathetic to the needs of client implementations too; when
>doing the P4P implementation (both client and server), we used (2).

I respectfully disagree; I believe #3 is easy to implement in the server
-- and is is MORE efficient.

Think about it. The server must convert the client's address string to a
byte array. That's a given; the server must use that byte array as the
index for all internal tables. A server can implement #3 by saving the
client's original string representation along with the byte array. I did
that in Java by creating an EndpointAddress class. It had the raw bytes
plus a string representation, and the hash code & equality test were based
on the byte array, not the string.

So the server creates an EndpointAddress for each source & dest address in
the request. The server uses the byte array part to search its internal
cost tables, and then just copies the string from the EndpointAddress into
the response.

If the server discarded the client's address string after parsing it, then
the server would have to convert the raw bytes back into a string. That's
not cheap, particularly if the server wants to use "::" to elide a
sequence of 0's.

So I believe #3 takes less cpu cycles on the server -- but slightly more
memory.

Furthermore, take a look at the JSON code that the server has to generate.
Yes, it's simpler than xml, but it's still a lot of overhead. My guess is
that will swamp any overhead of keeping the client's original address
string.

---

From: Richard Alimi <[email-masked]>
Date: Tue, 21 Jun 2011 09:02:02 -0700

Hi Bill,

> not cheap, particularly if the server wants to use "::" to elide a

With #2, if you wanted to also optimize for CPU at the server side (at
the cost of memory), you can keep pre-encoded versions of the
addresses cached and return those instead. That would have the effect
of the memory increase being O(1) time per address instead of O(number
of clients).

> So I believe #3 takes less cpu cycles on the server -- but slightly more

That said, I'll note that above I didn't necessarily say less CPU
cycles. My concern was increased implementation complexity (due to the
increased coupling on knowing the format of the users request) which
makes it more difficult to scale across multiple servers that might be
responsible for handling a request.

> that will swamp any overhead of keeping the client's original address

If you still feel strongly, it seems like we are at an impasse among
the two of us. That's fine and it can be resolved by the WG and we'll
update the document according to what the WG decides.  There are
considerations on both sides of the issue which have been recounted.
At this time it would be good to get feedback from others in the WG to
help resolve the debate.

To summarize, there are 3 possible solutions I think:
(1) Change the draft to make there be a single canonical format (that
is, give stronger wording than RFC5952)
(2) Require that for endpoint cost queries and endpoint property
queries, the ALTO Server gives IP addresses in the same exact format
as was in the request. (the wording in the draft can be adjusted, but
please correct me if the sentiment is incorrect)
(3) Leave the draft as-is, and let the server decide the particular
address format.

Is that a fair and objective summary of the options? If not, please correct me.

Thoughts from others in the WG on how to move forward?

Thanks,
Rich

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