Re: [RRG] Why delaying initial packets matters

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Marshall Eubanks <tme@multicasttech.com>

    > many simple web pages have in them pieces from other servers and other
    > IP addresses (banner ads are frequently done this way) and so this
    > could put a real performance hit on web page load times in the real
    > world.

Perhaps, but I'll note that interspersing of content in this manner also, in
theory, requires a DNS lookup for each of these included pieces, since they
are generally referred to via a DNS-based URL. (I can make that assertion
because I regularly trawl my web cache to find new sources of advertising
content which I can block, and I don't see many which are IP-address based.)

If the DNS resolution isn't proving problematic, it's probably because a
relatively small number of sites are involved (my list of blocked sites is
not that large), and the DNS records for them are getting cached relatively
close to the user machines (e.g. in a local DNS server). Ad content seems to
come either from the same server as the rest of the content, or from a small
number of ad providers.

That being the case, I would think the same would be true of EID->RLOC
bindings; there won't be that many, and in a system with decent caching,
requests for those bindings will be resolved 'close' to the ITR.


As a more general comment, I don't think we're going to be able to predict
accurately the performance of this kind of system (especially if it makes
heavy use of caches, as I think any well-designed system of the kind ought
to), nor the actual problems we are likely to see in service.

Networking work has a long history of theoretical analyses that purport to
show that approach X won't work - only to find that it does, in practise. (I
am reminded of one series of analyses by a faculty member at MIT-LCS which
'showed' that contention networks such as Ethernet wouldn't work 'well' in
high-load situations, which were a factor in the decision to work on token
rings at MIT. Ethernet, as we all know, does work quite well in practise,
because they basically never operate for long in those high-load regions.)

So I think probably the best thing to do is prototype a system, and try it
and see what happens.

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg