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

From: Robin Whittle <[email-masked]>
Date: Sat, 16 Feb 2008 07:49:56 +1100

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.

I was also thinking about BitTorrent, but that is not much of a
problem, since it is a non-real-time operation and takes a while anyway.

> If all of this is coming from one server farm, all is well and
> good. But, what if (like Joost) these streams are being provided
> by P2P ? 

I hadn't heard of real-time video delivery, but it doesn't surprise
me that it exists, and I hadn't assumed it does not or would not exist:

  http://en.wikipedia.org/wiki/Joost
  http://en.wikipedia.org/wiki/P2PTV

Minutes later I am running TVUPlayer and Joost.  Neither has an
obvious stop or pause button, so many users will leave the thing
running when they aren't actively watching - just like real TV.  I
guess these real-time P2P applications are going to be very widely
used, sucking data across the world even when no-one is watching -
burdening ITRs all around the world and therefore any pull-based
mapping database system.

Perhaps when we think of adding delays to the start of Internet
communications, we think along well known lines:  "TCP means two
mapping lookups, plus perhaps one or more for the DNS which preceded
it."  This is textbook stuff, but what is going on in the wild?

Delays to a single TCP session, for instance for a website, is
enough of a concern, but real-time P2P involves arbitrary numbers of
streams of packets, to and and from hundreds of millions of hosts
(later billions), without any DNS and with the expectation that the
packet is, in general, delivered immediately.

Adding any delays to initial packets will impact these systems in
some way.  In the one "session" the packets could be coming from any
number of hosts all over the world, and that set of hosts could be
changing all the the time.  While UDP-based P2P networks don't
assume reliable delivery, any delays in "initial" packets would
affect packets in the middle of a session, and so degrade the
service's quality, in addition to its start-up time.

 - Robin

--
to unsubscribe send a message to [email-masked] 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

---

From: "William Herrin" <[email-masked]>
Date: Fri, 15 Feb 2008 17:54:13 -0500

>  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 [email-masked] [email-masked]
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Scott Brim <[email-masked]>
Date: Tue, 19 Feb 2008 11:41:37 -0500

I'm not sure I understand all of this message, but it seems that you
are suggesting that every site have both non-globally-routed EIDs
(found by map&encap) and globally-routed addresses (found by BGP), for
different purposes.  

First, this does not appear to cut down on any of the rate*state
problems we are struggling with.  Some sites might not need
multihoming for the endpoints they keep using globally routed
addresses for, but not many.

I can see having whole *sites* globally routed or mapped.  That's
guaranteed to happen and may be the case forever, which is why we talk
about usually talk about "interworking" and "coexistence" instead of
"transition".  Having two systems running in parallel covering the
same territory doesn't remove any problems and adds complexity.  I
respect the goal but this isn't the answer :-).

Regarding mobile nodes, you say "clients" may be willing to get
temporarily assigned "addresses".  In that case the problems are the
same whether you use globally routed addresses or non-globally-routed,
mapped ones.

> space and Fast space, and then choose the one best suited to his

I understand PI but not "Fast".

Thanks ... Scott