ICM Workshop on Web Caching

Warsaw, Poland, 30 September - 1 October 1996

Multicast IP & Web Caching

Martin Hamilton, Loughborough University

MARTIN@MRRL.LUT.AC.UK

Multicast IP ?

• Send messages to multicast groups - class D address and port number, e.g.
  224.2.253.119 & 42148 for Radio Free Vat :-)

• Every application which has registered to receive messages sent to this group sees the message - contrast with unicast and broadcast.

• Propagation can be limited by
  • TTL scoping - decrement message's TTL for each router hop and stop when it runs out

  • admin scoping - certain routers told not to pass messages destined for certain groups any further

Multicast & Web caching

• Can't rely on domain name based routing, e.g. for .com and .net, but not clear how multicast can help ?
• Plus... TLDs are being opened up!
• Servers have to figure out which caches to peer with.
• (Auto-?)Reconfiguration on failure.
• (Auto-?)Selection of "best" peer.
• Whose bandwidth ?

Browser support

• Autoconfigure proxy server(s), e.g. via
  SVRLOC (draft-ietf-srvloc-protocol-14.txt), though this could be done without multicast, e.g. via ACAP
  (draft-myers-acap-spec-00.txt).

• Do without proxy servers altogether, or augment proxy server model by adding indidividual browsers' caches.

• Multicast aware stacks for MacOS and Win* aren't particularly widespread, though appearing in new installs - e.g. Win95 and Open Transport. Buggy ?

• Hard to deploy in browsers ? Have to be supported out of the box to be successful ?

Finding target server

• Dealing with communication between the proxy server and the server actually making the resource available.

• URL or server's domain name becomes a token used in (say) multicast ICP request, rather than a recipe for requesting the object ?

• Could be accomplished without multicast by round-robin DNS entries and (with more finesse, but not yet) SRV records
  ( draft-gulbrandsen-dns-rr-srvcs-03.txt), but this hasn't happened - e.g. replicated clip-art repositories.

• Requires cooperation from server authors and Web server maintainers.

Proxy to proxy

• Sites...
  • Individual site probably only has one or two Internet connections, and is fairly clear about routing policy (i.e. simple & fairly static rules ?)

  • Might want to multicast if other sites readily reached, e.g. ac.uk case, or want to peer with other local machines.

• ISPs...
  • Might want to peer with other ISPs or other local machines, e.g. LINX case.

  • Might want to peer with parent ISP's servers, or servers in other countries, e.g. NLANR case.

Conclusions

Multicast can be useful Right Now in cutting down on traffic where groups of servers are peering.

Anything more ambitious is a long-term thing - have to get server and browser authors and perhaps Web site maintainers involved.

Routers are still mostly Unix boxes running IP-in-IP tunnelling (currently something like 60% versus 40% native routing), but multicast routing gradually being incorporated into the unicast routing infrastructure - for info see
<URL:http://www.cl.cam.ac.uk/mbone/>.

These aren't particularly suited to handling large volumes of Web traffic ?

Global MBONE topology isn't always optimal - e.g. multicast from (ac.)UK to USA goes via unicast tunnel to Stockholm but then has to share the same physical link to the States which goes via London! Local/regional multicast use may be most appropriate.

Multicast not particularly compatible with firewall - no connection establishment, random ports & addresses!

Who do you trust ? Send multicast ICP request to well known group, but only act on replies from servers you have a reciprocal arrangement with already ?

PS Also some scope for (cache/target) server (and document?) announcements via multicast, perhaps with the Session Description Protocol used by sdr ?
(draft-ietf-mmusic-sdp-01.txt).