Subject: [alto] Large cost-map requests

From: Bill Roome <[email-masked]>
Date: Wed, 31 Aug 2011 09:26:45 -0400

If a server has 1,000 pids, the JSON-encoded full cost map could take >30
megabytes. 10,000 pids -- ouch!
 As a result, a server with a large number of pids may be reluctant to
return the full cost map -- or maybe even the full network map.

I see several possible solutions:

1. Require compliant servers to give the full cost map, no matter what it
takes. If that stresses the server, tough! Don't define that many pids.

2. Make the full cost map service optional.

3. Add an E_REQUEST_TOO_LARGE (or whatever) error code to section 7.4.3,
and allow a server to return that if a request is excessive.

4. In the ALTO spec, document that a server may return the existing HTTP
error code "408 -- Request Timeout" if the cost map is too large.

#4 is the easiest, and in any case, we can't stop a server from returning
that status code. But if the server does, the client can't tell if it's a
permanent rejection or just a transient glitch. #2 & #3 make it clear that
the server simply won't return the full cost map, period.

	- Bill Roome

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 31 Aug 2011 13:33:57 -0500

Bill Roome wrote:
> If a server has 1,000 pids, the JSON-encoded full cost map could take
> >30 megabytes. 10,000 pids -- ouch! As a result, a server with a
> large number of pids may be reluctant to return the full cost map --
> or maybe even the full network map.
>
> I see several possible solutions:  [...]

There is actually a 5th option --- take a one-time hit for
sending a large map, and subsequent to that, send incremental
updates.

There has been some discussion of incremental updates in
hallway conversations and such; the Quebec City IETF
minutes [1] reflect this.

[1] http://www.ietf.org/proceedings/81/minutes/alto.html#proto

Thanks,

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