Re: [RRG] Re: Map-encap space for "server" vs. "client" end-users?

[Robin Whittle <rw@firstpr.com.au>]

Short version:

   I still think the new map-encap space has to be free of stuff
   like significant initial packet delay, since we have to make it
   attractive to large and small end-users.  I would appreciate
   some debate of my message about this:

     Large companies with PI, small with map-encap space?
     http://psg.com/lists/rrg/2008/msg00275.html


Hi Bill,

You wrote, in part:

> By hybrid, I mean a system where the shorter, typically PA
> prefixes continue to be routed via BGP as they are today while
> the longer, frequently PI or TE prefixes are shifted to
> map-n-encap as driven by the system's economics.

OK - this means the map-encap address space does not completely
replace conventional BGP-managed prefixes.  However I am confused
with your use of "PA", "PI" and "TE" here.

I am using the term "hybrid" only as part of "hybrid push-pull",
which means something else.


>> I am sure there are many end-users, large and small, who want 
>> stable, portable, multihomable address space to run both
>> servers and client hosts on.  So trying to decide which
>> end-users are "server" end-users and which are "clients" would
>> be difficult or impossible.
> 
> That's exactly my point: the choice should (and ultimately will)
> be made by the folks purchasing Internet service. Our job
> shouldn't be trying to figure out what they should or must do; it
> should be giving them as many quality parallel options as we
> reasonably can so that they can select the best fit.

Yes, however many options there are, if we want these options to be
widely used - which we do to solve the routing scaling problem -
then we have to ensure the end-users who adopt these options gain
direct, immediate, benefits.


>> For web servers, game servers etc. having a bunch of these,
>> especially for a bunch of customers, would be extremely 
>> disruptive and expensive for the end user - the hosting or 
>> self-managed server company - and their customer end-users.
> 
> I disagree and I'll tell you why: given the option to reference 
> subservers by DNS name or by IP address, web site designers have 
> overwhelmingly chosen to reference them by name and accept the
> extra lookup delay. This is the preference that the operations
> folk have clearly demonstrated to us with their actions - that on
> initial access to a server, a mild lookup delay is acceptable for
> the sake of convenience.

OK.  Renumbering a bunch of web servers also means having to alter
the records in a bunch of nameservers - not all of which would be
controlled by the hosting company.

Quite a few web servers host dozens of sites, so renumbering one
such server means chasing around and individually changing zone
files in dozens of name servers, many of which are not going to be
accessible to the hosting company.  That means the company whose web
site it is needs to get involved, which makes the hosting company
look bad, leads to lots of support calls etc.


>> I assume that by "Fast space" you mean the map-encap type of
>> space.
> 
> The opposite. "Fast" space is highly aggregated PA space which
> runs as bare IP over the backbone without going through a
> man-n-encap scheme and thus suffering no lookup delays or slow
> initial pathing.

Not all map-encap schemes involve such delays!


>> I think most existing and new "server hosting" companies would
>> avoid the new system like the plague.  Competitors with the
>> original, authentic, good-ol-days RLOC space would be pointing
>> out the superior responsiveness of their servers compared to
>> the slower nature of the new-fangled plastic map-encap space.
> 
> What's wrong with that? 

As Marshall Eubanks wrote in response to Jari Arkko:

   http://psg.com/lists/rrg/2008/msg00381.html

    However, it is not enough to work; it also has to be salable.

    I don't think that any system that imposes significant user
    delays will be commercially viable if other options are
    available, and it is hard to see how they would not be.

    If I represent a service provider without these delays, and
    you represent one with these delays, I can guarantee you that
    you will not like my marketing materials pointing this out,
    and telling potential customers something like "ask how long
    it takes Jarinet to connect to the web." I have been on the
    loosing end of such campaigns; it is hard to fight simple
    facts with complicated explanations of why said facts are
    irrelevant most of the time.

    So, the delays cannot be "significant," which I would regard
    as meaning "being noticeably larger than typical DNS delays."
    Any such solution with significant user delays will be hammered
    in the marketplace.

    This is indeed likely to impose significant engineering
    constraints.

> If you're placing a /18 on the 'net, we
> can easily accommodate you with the hardware that's already
> deployed, let alone with hardware currently shipping.

I think you are saying that larger end-users might as well use the
conventional techniques we use today - a BGP advertised prefix.

> I'm more interested in the guy who has 5 servers he wants to put
> on the 'net and he never wants to have to deal with renumbering. 
> Map-n-encap would give him an option he doesn't have today, an
> option he wants to have. That's where the initial market for
> map-n-encap is: PI space for guys that are otherwise too small to
> have it.

I agree there is a huge market for this, but I believe we need to
make the map-encap address space equally attractive for all end
users, large and small, established, new and growing.


> Once map-n-encap exists, the definition of "too small" grows
> until it correctly balances with the needs of the folks operating
> the DFZ.

If map-encap space had deficiencies, such as frequent delays in
initial packets, then the big end-users (who have a choice whether
to adopt it or not) would avoid it like the plague.  Only the
smaller end-users, who can't afford or justify one or more /24s of
conventional BGP-managed PI space, would be choosing map-encap space
- because they have no other option.

I argue that the new address space must have no deficiencies which
affect end-users, and that it must be attractive to end-users of all
sizes:

  Large companies with PI, small with map-encap space?
  http://psg.com/lists/rrg/2008/msg00275.html


I would be glad if someone debated this.

  - Robin          http://www.firstpr.com.au



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