RE: some random questions

In the design the more you can simulate real end user browser behaviour the
better - CDNs exist to improve the end user experience. That means take into
account slow dial up links, browser caches and forward proxy caches deployed by
ISPs (CDNs that deliver cacheable content further improve the performance of the
sites they serve beyond just hosting content in their distributed servers)

-----Original Message-----
From: Duane Wessels [mailto:wessels_at_ircache.net]
Sent: Wednesday, May 31, 2000 6:59 PM
To: cdd_at_measurement-factory.com
Subject: some random questions

At the BOF in Lisbon, there seemed to be some agreement that a good way
to test CDNs is to create a "fake" content provider and have the CDNs
provide service for it. Measurements could be taken from a number of
dedicated clients scattered throughout the Internet. To further this
discussion, I'll ask a bunch of questions....

Does the fake content provider need to have real content? Does it need
to be HTML, JPG, GIF, and MP3s? Or can we use blobs of random bits?

How much content do we need? Whats the size of a typical content
provider? 100MB, 1GB, 1GB?

How dynamic is the content? Do pages/objects change during the test?
Do we want to measure freshness and consistency?

Is the location of the fake content provider significant? Does it need
at least T1 connectivity? Is a 10baseT interface sufficient?

How many measurement points do we need? 10? 100? more?

How long should the test run? one hour? one day?

One of the things we've found useful in cache benchmarking
is performance/price ratios. Are there "costs" that
should be included in CDN results, other than subscriptions?
Do some schemes require additional hardware?

Duane W.
Received on Mon Jun 05 2000 - 20:29:17 MDT