Re: [RRG] Why delaying initial packets matters - complex web pages & real-time P2P

["William Herrin" <bill@herrin.us>]

On Fri, Feb 15, 2008 at 3:49 PM, Robin Whittle <rw@firstpr.com.au> wrote:
> Marshall Eubanks wrote:
>
>  > Note, too, that 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.
>
>  I have been thinking of this, but this is the first mention of it on
>  the list.  This is a typical Internet usage where people have to
>  wait as it is, and would be waiting longer if any of the web servers
>  relied on LISP-ALT ITRs which did not yet have the mapping for the
>  particular EID in which the client is located.

Robin,

It seems to me that one assumption which has run heavily through this
thread is that man-n-encap would entirely replace the existing system
where the EID and LOC are the same. It strikes me that not only is
this unlikely, it would be undesirable as well.

I won't spend a lot of time on why outright replacing BGP is unlikely.
Suffice it to say that anything the size of the Internet has a great
deal of inertia and no map-n-encap scheme discussed so far has enough
punch behind it.

I will spend a couple paragraphs on why a hybrid system is a desirable outcome.

There are relatively few scenarios in which a client machine derives a
benefit from a static IP address assignment. Mobility, at least with
respect to long-lived connections. The occasional firewall admin where
inbound access to a resource has been restricted by source IP address.
Not a whole lot else.

Given a choice between a mild slowdown and the temporary assignment of
an IP address from a highly aggregated pool, most clients would elect
to use the temporary assignment.

Servers are a whole other can of worms. There are spam filters which
block and permit by IP address. There's lots of crappy software which
doesn't respect DNS TTLs. Renumbering servers is a difficult and
fault-ridden process. Given a choice between an extra delay equivalent
to a DNS lookup on every request and having to renumber, more than a
few server administrators would choose the extra delay... Especially
for email servers and other devices that move data in bulk where the
delay simply doesn't matter.


The conclusion, it seems to me, is that the desirable outcome is a
hybrid system in which a fellow in Operations can consider both PI
space and Fast space, and then choose the one best suited to his
particular application.

In other words, whether you favor LISP or IvIP or TRRP, your system
should be designed as a supplement to BGP, not a replacement. A
supplement which serves to enable PI space.

YMMV,
Bill Herrin


-- 
William D. Herrin herrin@dirtside.com bill@herrin.us
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

--
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