WWW-6 Bandwidth Utilization BOF: "Information Superjam"
This digest by Armando Fox.
Highlights of discussion:
- Martin Westhead, email@example.com,
Edinburgh Parallel (i.e. Super-) Comp. Ctr.
Preparing to do large-scale simulations of (pieces of)
Internet. Case study: UK cache performance, propose new
- Ernst Heiri, firstname.lastname@example.orgSwiss Acad. and
Research Network (SWITCH, provides services
to Swiss universities). Paying $1M/year for 4 Mbs transatlantic
link, caching is a big deal. Extensive caching network already
deployed in Switzerland.
- Alessio Bragadini, email@example.com, Univ. of
Pisa, Italy: same problems and approaches, but less money
- Per-Olov Andersson, <firstname.lastname@example.org>
Natl. Institute for Working Life, Sweden.
"Deregulation (therefore competition) is a major solution
to the bandwidth problems"
- Marc Abrams, <email@example.com>, Virginia
Studies network performance, caching
simulations and models. Interested in finding configurations
people would like to see simulated, finding "optimal" cache
hierarchies for various scenarios, and constructing a library of
models and results.
- Martin Winter, <firstname.lastname@example.org>, Knight-Ridder. Provide web front end to online
news/databases. Customers don't use because too slow; so their
problem is "last mile" connection.
- Armando Fox,
UC Berkeley. Distillation (transformation) proxy
work from WWW-5 etc. Interested in exploring networks of
cooperating proxies, to do distillation closer to servers before
the bottleneck link (since that link is no longer necessarily the
- Sam Johnson, <email@example.com>,
SGI. Became "Web bandwidth aware" last year talking
to European colleagues; wants survey of ideas/opinions so he can
do more considerate Web design for the bandwidth-impaired. :)
- Jim Mackey <firstname.lastname@example.org>
and Dara OhUiginn <email@example.com>,
Newbridge Networks (ATM switches, etc.)
"Problems would go away if people would just buy more of our
- Raphael Quinet, <Raphael.Quinet@eed.ericsson.se>,
Ericsson. Internet access over cellular; TCP and
HTTP performance over slow links. "Proxy pair" approach does
prefetching (it's a circuit connection), distillation (using UCB
Pythia code), HTTP improvements, etc.
- Andres Schmid, <firstname.lastname@example.org>,
Union Bank of Switzerland, Intranet
- Noam Camiel, <email@example.com>,
Hebrew Univ. Israel. How can Israel get more bandwidth?
- Jimmy Vo, <firstname.lastname@example.org>
Bay Networks. "Intelligence gathering".
- Brian Chiko, <email@example.com>,
- Felix Gaehtgens, The Double Helix, firstname.lastname@example.org , worldwide change
management; Internet access in
- Various "intelligence gatherers" and intersted observers: Liping
and Khoa Doan <email@example.com>,
Hughes STX. Alvaro Pombo <firstname.lastname@example.org>,
Newbridge Networks. Hui Wang <email@example.com>,
- Publishers vs. infrastructure operators on caching
- Martin Winter: what about dynamic pages?
- Marc: publishers want a "distributors" model: mirror sites but
no caches per se
- Raphael: what about servers interested in "click trails"?
- All European countries have severe bandwidth constraints leaving
the country, and caching has been aggressively deployed. In some
countries, internal bandwidth is at least as much an issue
as transatlantic. Many believed this would be alleviated with
- The role of transformations; caching doesn't decrease last-mile
latency. Can they be used to improve cases where bottleneck link
is behind the cache?
- Price of long haul bandwidth not decreasing. Dara and others
believe this would be alleviated with deregulation. Armando
points out that even so,
- Marc: Caching is not a fad. Bandwidth scarcity is a steady state
reality, since individual users generall have access to same
technology as backbone providers.
- Jim and Dara: the world of "enough bandwidth for all" can be a
reality with enormous (ATM) BW in the fabric, just not tomorrow.
Armando and others: Historical precedent suggests BW will be
soaked up as soon as available; ATM has nontrivial routing and
buffering problems (bursty traffic); routing complexity is getting
routing pathologies getting more egregious (e.g. Sweden ->
London -> NY -> Chicago -> LA -> ...back... -> Belgium). Marc
agrees and recommends all read Paxson's
SIGCOMM 96 paper.
Many skeptical that there is a
steady state solution.
- Sam: How much responsibility for accommodating client constraints
should be taken by content creators
vs. protocol/format designers vs. infrastructure providers?
- Marc: don't nec. have to "buy your way out" of a BW squeeze.
Sometimes reallocation of poorly-utilized resources. Ex:
Virginia stopped using satellites and reinvested money for ATM's
for transmitting digital video.
- Alessio: What abuot prefetching? Explorer 4.0 does prefetching
"while your machine is idle", and incorporates some Pointcast
technology. (Groans from peanut gallery)
- Armando: app developers can help by moving in the direction of
- Why isn't mcast being aggressively adopted?
- network managers already have too much to do just keeping
the networks running
- no commercial products that exploit it, so lack of
incentive for deployment
- mcast can easily overtake TCP traffic
- Server redirection to mirrors or caches
- Felix: should always do it for "far away" hosts. Has
worked well in example of Internet-developing countries
(web server in Peru).
- Armando: redirect is a mechanism, not a policy. Optimal
policy is almost certainly based on dynamic decisions.
Cited Stemm et al. SIGMETRICS
- Armando: check out IBM Womplex
A cut-and-paste email list
Martin Westhead <firstname.lastname@example.org>,
Ernst Heiri <email@example.com>,
Alessio Bragadini <firstname.lastname@example.org>,
Per-Olov Andersson <email@example.com>,
Marc Abrams <firstname.lastname@example.org>,
Martin Winter <email@example.com>,
Armando Fox <firstname.lastname@example.org>,
Sam Johnson <email@example.com>,
Jim Mackey <firstname.lastname@example.org>,
Dara OhUiginn <email@example.com>,
Raphael Quinet <Raphael.Quinet@eed.ericsson.se>,
Andres Schmid <firstname.lastname@example.org>,
Noam Camiel <email@example.com>,
Jimmy Vo <firstname.lastname@example.org>,
Brian Chiko <email@example.com>,
Felix Gaehtgens <firstname.lastname@example.org>,
Liping Di <email@example.com>,
Khoa Doan <firstname.lastname@example.org>,
Alvaro Pombo <email@example.com>,
Hui Wang <firstname.lastname@example.org>