Subject: [RAM] The mapping problem: rendezvous points?

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 8 May 2007 18:52:56 +0200

We basically have two choices for the mapping mechanism: work on- 
demand and cache the result for some time, or flood everything ahead  
of time. Both approaches are problematic: caches are vulnerable to  
sudden changes in the mix of destinations in the traffic, and there  
is a delay between the moment routing information is needed and the  
moment it becomes available. Then again, BGP shows that flooding  
everything everywhere isn't so great when you can't control the size  
or volatility of the underlying data.

An analogy in the real world: large stores carry very many items by  
way of many distributors. Rather than have every store maintain a  
direct relationship with every vendor and suffer a huge information  
explosion on both ends, there is stuff in the middle that handles  
distribution so each vendor and each store only deals with a limited  
number of other organizations.

Something like that may be useful in our problem space, too. The way  
I imagine this is by having rendezvous points where the reachability  
information for subsets of the network comes together. For instance,  
as a large ISP, I could have a small number of routers handle a  
certain /8 out of IPv4 space. All the other routers route their  
traffic for this prefix to the closest one of the rendezvous routers  
in question. These then forward the traffic as per more specific  
routing information if possible, or encapsulate it if necessary.

The rendezvous point is where traffic and routing information all  
come together.

Compared to an on-demand model, this has the advantage that there are  
no delays and no caching issues. Compared to a flooding model, it has  
the advantage that the full specific information is only required in  
relatively few places. This can work with both a very small number of  
very large routers, or a much larger number of much smaller routers,  
as long as the aggregate capacity in routing table size and bandwidth  
is adequate.

The downside is that not having the same information available  
throughout an AS increases operational and/or protocol complexity.

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 11:18:58 -0700

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2007 9:53 AM
> To: [email-masked]
> Subject: [RAM] The mapping problem: rendezvous points?
> 
> of time. 

I disagree with the word "everything".  The two high level choices are:

PULL: work on-demand (which results in deterministic loss and hence
adversely affects applications) and cache the result for some time

PUSH: learn enough information (which may or may not be everything)
ahead of time so that one has enough information to immediately forward
a packet when it arrives.  It would be desirable to learn log(N)
information (and everyone may not learn the same information).

Flooding everything is a type of PUSH, and has scalability issues.
DHTs distributing log(N) information to each node are another type of
PUSH, and don't have the scalability issues.

Rendezvous points as you suggest below are another type of PUSH, where
the non-rendezvous points have a small amount of information, but if I
understand you correctly, the RPs still have the same scalability issues
as flooding everything.

-Dave

> Both approaches are problematic: caches are vulnerable to

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 May 2007 12:44:21 -0700

> understand you correctly, the RPs still have the same scalability  

For the last few months I have been sporting a new saying, inspired  
by our esteemed Yakov:

"Pull doesn't scale, Push doesn't scale, pick one".  ;-)

Dino

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 12:53:16 -0700

> "Pull doesn't scale, Push doesn't scale, pick one".  ;-)

Unfortunately, that's simply not true.  Pull does scale.  See DNS.   
Perhaps a more accurate saying would be:

	"Push doesn't scale, pull is slow, pick one."

As always, it's a time/space tradeoff.

;-)

Tony

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 13:00:06 -0700

I disagree with Yakov for a completely different reason.

Pull scales, but is slow and can break apps as a result.
Push *everything* doesn't scale.
Push DOES scale as long as you don't push everything but only push
log(N)
stuff.

So I disagree with "push doesn't scale" unless you define "push" as
"push everything", in which case I disagree with "pick one".

-Dave

> From: Tony Li [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2007 12:53 PM
> To: Dino Farinacci
> Cc: Dave Thaler; [email-masked]
> Subject: Re: [RAM] The mapping problem: rendezvous points?
> 
>

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 13:03:24 -0700

Dave,

> information (and everyone may not learn the same information).

Thanks for the summary.  I think we should also point out that there  
are a variety of hybrids, where some parts of the mapping are pushed  
and some parts of the mapping remain to be pulled.

> PUSH, and don't have the scalability issues.

I'd claim that that's a hybrid, where you push information to some  
locations, but since no system has a full mapping, you end up pulling  
the needed entries at some point.  I agree that it avoids the  
scalability problem and hope folks take careful note of this.

> understand you correctly, the RPs still have the same scalability  

If I understand Iljitsch correctly, the rendezvous point is another  
hybrid model where full information about portions of the mapping are  
pushed to certain locations.  However, rather than pulling detailed  
information, the remainder of the network redirects traffic to the  
rendezvous point.  This trades off the latency of pulling the  
detailed information against additional stretch in the data plane  
(and latency there).

Again if I understood correctly, each rendezvous point would be  
responsible for only a fixed portion of the mapping, so there isn't a  
scalability issue.

Tony

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 08 May 2007 13:08:36 -0700

Dave,

> I disagree with Yakov for a completely different reason.

Just for clarification, "Pull doesn't scale, Push doesn't scale,
pick one" is coming from Dino, not from myself. So, you disagree with Dino,
not with me.

Yakov.

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 8 May 2007 16:11:01 -0400

Dear Iljitsch;

On May 8, 2007, at 12:52 PM, Iljitsch van Beijnum wrote:

> demand and cache the result for some time, or flood everything  
> ahead of time. Both approaches are problematic: caches are  
> vulnerable to sudden changes in the mix of destinations in the  
> traffic, and there is a delay between the moment routing  
> information is needed and the moment it becomes available. Then  
> again, BGP shows that flooding everything everywhere isn't so great  
> when you can't control the size or volatility of the underlying data.
>
> distribution so each vendor and each store only deals with a  
> limited number of other organizations.
>
> Something like that may be useful in our problem space, too. The  
> way I imagine this is by having rendezvous points where the  
> reachability information for subsets of the network comes together.  
> For instance, as a large ISP, I could have a small number of  
> routers handle a certain /8 out of IPv4 space. All the other  
> routers route their traffic for this prefix to the closest one of  
> the rendezvous routers in question. These then forward the traffic  
> as per more specific routing information if possible, or  
> encapsulate it if necessary.
>

Of course, with RP's come the issue of RP discovery - how do I know  
where the RPs are in your /8 ? In IPv6 multicast, the so-called  
embedded RP concept (RFC 3956) has worked fairly well, where the  
address of the RP is embedded directly in the multicast addresses.  
Unless DNS is going to do, I think that something like this should  
IMO be built into any future RP schemes.

Regards
Marshall

> Compared to an on-demand model, this has the advantage that there  
> are no delays and no caching issues. Compared to a flooding model,  
> it has the advantage that the full specific information is only  
> required in relatively few places. This can work with both a very  
> small number of very large routers, or a much larger number of much  
> smaller routers, as long as the aggregate capacity in routing table  
> size and bandwidth is adequate.
>

---

From: David Conrad <[email-masked]>
Date: Tue, 8 May 2007 13:16:58 -0700

Hi,

> adversely affects applications) and cache the result for some time

What applications are adversely affected by a delay in transmitting  
the first packet?  How do such applications work in today's "best  
effort" Internet?

Thanks,
-drc

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 13:19:57 -0700

> Sent: Tuesday, May 08, 2007 1:03 PM
> To: Dave Thaler
> Cc: Iljitsch van Beijnum; [email-masked]
> [...]

I agree there are hybrid cases possible, but what I was saying is not a
hybrid at all.

In hybrid schemes it comes down to whether there is any case of "slow"
or not.  

For example, in one class of hybrid schemes:

PUSH is used to get log(N) information such that any packet can be
immedidately forwarded upon arrival, and PULL is used in parallel to
forwarding to obtain a more optimal destination for future traffic.
This one is not problematic.

PUSH is used to get some information, but there remain cases where
a packet can arrive and PULL must be used before the packet can be
forwarded (i.e. encapsulated) somewhere.  This one is problematic
for the same reason as PULL.

So as long as a hybrid is PUSH (not everything) with PULL _as an
optimization_, I claim it's better than where PULL is _a necessity_ and
PUSH is just an optimization.

-Dave

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 13:27:38 -0700

Applications generally work fine with random loss.
They work less well with _deterministic_ loss.

Some common application models that are adversely affected by PULL:

1) Client resolves a name to a list of addresses, and tries each one 
(with some timeout since there's no guarantee of response) until a
connection succeeds.  Here if the first packet(s) to an address fail
(or take too long, but failure happens in PULL schemes once a queue
overflows) then it fails over to the next address.  As a result it will
connect via a different path to a different server (and see possibly
different results, either quantitatively or qualitatively).

2) Client resolves a name to a list of addresses, and tries each
one in parallel and chooses the first one to succeed.  Here a 
deterministic delay (say a closer address is un-cached, but one
far away is cached for some other reason), again causes the inefficient
one to be chosen.

3) Server responds to a simple client request via an asymmetric path.
No DNS occurs here, and the response goes via a router not involved
in the client-to-server direction.  A cache miss causes a loss
(since there's a huge number of such clients, a non-negligible
percentage will be dropped since you can't queue all the packets
waiting for the delay).  As a result, the client never gets the response
and either gives up or fails over to a different server (which might
have the same problem...)

The above are just examples of common application classes which show
why I personally consider PULL schemes to be a non-starter.

-Dave

> From: David Conrad [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2007 1:17 PM
> To: Dave Thaler
> Cc: [email-masked]

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 13:28:48 -0700

Right, my mistake.  Yakov is fine ;-)

-Dave

> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Tuesday, May 08, 2007 1:09 PM
> To: Dave Thaler
> Cc: Tony Li; Dino Farinacci; [email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 8 May 2007 16:42:16 -0400

Dear David;

> the first packet?  How do such applications work in today's "best  

If delays are as much as several seconds, that will start to bring  
serious complaints from webhosts,
but the needs of video are more stringent.

In IPTV / Internet Broadcasting / Video Conferencing, there is a  
desire to

- start / change channels & broadcasts in 100's of milliseconds and
- not lose basically any packets

and that is why much of this traffic now goes over L2VPNs or L3VPNs.  
FEC will help with the
second, not the first.

Regards
Marshall

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 May 2007 13:53:36 -0700

> As always, it's a time/space tradeoff.

Pulling implies caching. And some have said (not me) that caching  
doesn't scale.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 8 May 2007 13:55:02 -0700

> pick one" is coming from Dino, not from myself. So, you disagree  

Sorry Yakov. No one picked up your quote about topology and  
addressing. That is what I based the "syntax" of my saying.

Dino

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 14:09:31 -0700

Dave,

> This one is not problematic.

Since the first packet is forwarded with suboptimal information,  
there will be a certain amount of additional stretch.  In addition,  
when the optimal information arrives, the change in path can  
potentially cause packet reordering, which is definitely problematic  
for a variety of applications, as well as triggering slow start.

> PUSH is just an optimization.

I think that your claim is equivalent to saying that you prefer  
initial sub-optimality to initial latency.  I'm not yet convinced by  
this.  If the mapping client is in fact the host, it would seem that  
we could mask any initial latency.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 14:35:22 -0700

Dave,

> Some common application models that are adversely affected by PULL:

It seems to me that these are really more about stack implementation  
models than about applications.  In any case...

> different results, either quantitatively or qualitatively).

Differing paths already happen today in the case of hosts with  
multiple A records or load balancing kit.  The truly problematic part  
about this is that with multiple possible mapping results, sequential  
testing can lead to l
a large initial delay.

> far away is cached for some other reason), again causes the  

This could be alleviated by having the traffic deferred until either  
a sufficient quantity of information had arrived, some heuristic  
threshold for 'good' information had been reached, or if later  
updates caused rerouting.

> have the same problem...)

This could be eliminated by moving the mapping client to the host.

Tony

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 15:11:37 -0700

> for a variety of applications, as well as triggering slow start.

Absolutely agree.  Of course reordering is less problematic than loss.

> we could mask any initial latency.

The host is not incented to change to deal with routing scalability.
That's why I like the LISP approach, as the changes are done in places
(and by people) who actually experience the pain.

-Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 May 2007 15:43:39 -0700

> (and by people) who actually experience the pain.

IPvLX gives IMHO a nice example of a map-and-encaps
architecture that locates the ITR as close as possible
to the application endpoints. But, it is still a router
even though it may be co-located with a host function.

When the ITR and application endpoints are in very close
proximity, I don't see a problem for the pull model.

Fred
[email-masked]

---

From: Tony Li <[email-masked]>
Date: Tue, 8 May 2007 15:46:40 -0700

Dave,

> The host is not incented to change to deal with routing scalability.

Fortunately, the locator/ID split brings changes to mobility and  
renumbering.  It also morphs the fundamental Internet architecture.   
Don't these also incent the host to change?

> (and by people) who actually experience the pain.

Unfortunately, doing LISP inside the site or even in the PE router  
isn't exactly co-located with the major pain felt in the core, and it  
results in a solution that is far from optimal.

Tony

---

From: David Conrad <[email-masked]>
Date: Tue, 8 May 2007 15:58:55 -0700

Dave,

> They work less well with _deterministic_ loss.

I would've thought the opposite would be true.

> connection succeeds.
> ...
> one in parallel and chooses the first one to succeed.
> ...

Since both of these are already relying on a pull mechanism at the  
initiation of a transaction, it isn't clear to me how they would be  
significantly more adversely affected by using a pull-based mapping  
mechanism.

> in the client-to-server direction.

This case would indeed cause an increase in latency.

> why I personally consider PULL schemes to be a non-starter.

I was wondering if you had concrete examples of existing applications  
that would fail with an increase in initial packet latency.

Rgds,
-drc

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 16:23:06 -0700

Tony Li [mailto:[email-masked]]
> Don't these also incent the host to change?

Renumbering doesn't incent the host to change.  As I mentioned in the
Intarea presentation, renumbering requires MANY components to change
(hosts, firewalls, IDS's, enterprise inventory applications, etc.)
Changing hosts by themselves doesn't solve anything... we learned this
from IPv6.  Renumbering provides strong incentives to NOT change hosts
but instead change site border routers (or something else outside most
of the network that wants PI space).

Mobility incents _some_ hosts to change... but just the ones that are
mobile.
That's why Mobile IPv6 has an easier deployment model than say HIP...
with MIPv6 someone who changes still gets benefit (with help from a 
Home Agent) when talking to arbitrary correspondent nodes.  The
correspondent nodes aren't strongly incented to change, and don't have
to.

-Dave

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 08 May 2007 18:30:24 -0500

Dave,

I've heard variations on the "deterministic loss" thing in several places 
recently, and I don't understand all the context, but people have usually 
been talking about deterministic loss AT THE BEGINNING of a TCP connection, 
or AT THE BEGINNING of an MPEG stream where you're losing complete images 
and then all you receive for a while is deltas from the image you lost.

Are you talking about more than this?

Spencer

---

From: Dave Thaler <[email-masked]>
Date: Tue, 8 May 2007 16:39:43 -0700

Spencer Dawkins [mailto:[email-masked]]
> Are you talking about more than this?

That's mainly what I'm talking about.  The generalization is that
deterministic loss in response to any application-initiated request
is bad... e.g. deterministic loss at the beginning, or on every send,
or at the end (which may leave state hanging on the other end for long
periods of time until it expires).  However, I think the main case I've
seen people actually proposing is deterministic loss at the beginning.

(And I'm using the term "deterministic" loosely to mean "non-negligible
chance".  And "random" to mean "negligible chance".)

-Dave

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 8 May 2007 16:43:27 -0700

> seen people actually proposing is deterministic loss at the beginning.

But, if your mapping occurs as a function of the FQDN
lookup and before any data packets are sent, where is
the deterministic loss?

Fred

---

From: Ted Hardie <[email-masked]>
Date: Tue, 8 May 2007 21:52:29 -0700

At 6:30 PM -0500 5/8/07, Spencer Dawkins wrote:
>I've heard variations on the "deterministic loss" thing in several places recently, and I don't understand all the context, but people have usually been talking about deterministic loss AT THE BEGINNING of a TCP connection, or AT THE BEGINNING of an MPEG stream where you're losing complete images and then all you receive for a while is deltas from the image you lost.

It's my understanding that some applications facing the media stream aspect of this
will negotiate the codec or codec parameters to degrade the quality in the face of
this.  This degradation can last for the duration of the stream, or renegotiation
can take place but result in slow restoration of quality.

				regards,
					Ted

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 May 2007 09:15:22 +0200

> that would fail with an increase in initial packet latency.

Aside from the fact that Marshall provided such a list, depending on 
where the split happens, if it's not in the host, then no one can 
guarantee that the loss is in fact the first packet, or that it's just 
one packet.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 May 2007 09:16:24 +0200

> correspondent nodes aren't strongly incented to change, and don't have

Which may explain why mobility hasn't been IPv6's "killer app".

Eliot

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 9 May 2007 06:15:37 -0400

On May 9, 2007, at 12:52 AM, Ted Hardie wrote:

>> I've heard variations on the "deterministic loss" thing in several  
>> places recently, and I don't understand all the context, but  
>> people have usually been talking about deterministic loss AT THE  
>> BEGINNING of a TCP connection, or AT THE BEGINNING of an MPEG  
>> stream where you're losing complete images and then all you  
>> receive for a while is deltas from the image you lost.
>

That it correct. Note that the application could decide that the  
session was not possible and drop it entirely.
(Say, if there was only 1 bit rate on offer.)

If the interruption is as long as a couple of seconds, that is quite  
possible.

Regards
Marshall

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 09:03:00 -0700

On May 9, 2007, at 12:15 AM, Eliot Lear wrote:
> David Conrad wrote:
>> I was wondering if you had concrete examples of existing  
>> applications that would fail with an increase in initial packet  
>> latency.
>
> Aside from the fact that Marshall provided such a list, depending  
> on where the split happens, if it's not in the host, then no one  
> can guarantee that the loss is in fact the first packet, or that  
> it's just one packet.

And this is different than the existing Internet how (and it doesn't  
matter if it is in the host or not)?

My point is that applications already must cope with the fact that  
the Internet is "best effort" and stuff happens to cause packet loss  
or delay.  A pull-based mapping redistribution model implies an  
increased amount of latency on cache misses (most likely on the order  
of tens to hundreds of milliseconds, not seconds).  Internet  
applications that I know of already must deal with variable latencies  
of these orders of magnitude and I was asking for pointers to  
applications that couldn't.

Thanks,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 May 2007 18:13:47 +0200

I feel like we've had this argument before.  But...

>> guarantee that the loss is in fact the first packet, or that it's 
>> just one packet.
>
> My point is that applications already must cope with the fact that the 
> Internet is "best effort" and stuff happens to cause packet loss or 
> delay.  A pull-based mapping redistribution model implies an increased 
> amount of latency on cache misses (most likely on the order of tens to 
> hundreds of milliseconds, not seconds).  Internet applications that I 
> know of already must deal with variable latencies of these orders of 
> magnitude and I was asking for pointers to applications that couldn't.

This is not your father's Internet.  There are many applications out 
there today that are NOT really delay or drop tolerant, and the truth is 
that they've always been there.  Voice, video, and UDP-based NFS come 
immediately to mind, as do high rate data transfers, which are 
particularly sensitive to multiple drops.  Some of these applications 
will "tolerate" a few drops by degrading end user quality.  If it's 
revenue generating that would be Bad, right?  And it's one thing to drop 
packets in the face of a failure.  It's quite another to drop them by 
design.  That's an engineering tradeoff that should be considered 
against whatever perceived benefit exists.

Eliot

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 09:39:58 -0700

Eliot,

On May 9, 2007, at 9:13 AM, Eliot Lear wrote:
> I feel like we've had this argument before.

Yep.  You and others keep asserting that a pull-based mapping  
distribution model is a "non-starter" because it "won't work".  I've  
been trying to get from folks _concrete_ examples of applications  
that "won't work" in the face of increased latencies on the order of  
10s or 100s of milliseconds after a cache miss.  In response I get  
vague handwaving about voice or video (I know from personal  
experience that UDP-based NFS works fine in the face of an initial  
packet delay of 10s of milliseconds) or descriptions about classes of  
applications that would appear to be degenerate cases and asymmetric  
routing that would likely have unpredictable performance  
characteristics with pull or push.

GIven the lack of data, it would seem we've descended to the realm of  
religion, so I'll give it a rest.

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 May 2007 19:10:37 +0200

David Conrad wrote:
> been trying to get from folks _concrete_ examples of applications that 
> "won't work" in the face of increased latencies on the order of 10s or 
> 100s of milliseconds after a cache miss.
I have a laundry list of issues with pull models, but they mostly 
evaporate if the host is involved.  I *like* DNS when the host is 
involved, for instance.  But when the device making the query *isn't* 
the host, things get messy for the application (discussed below).  Then 
there are security and continuity considerations.  Those are really fun, 
and they don't even involve the application.  Consider what happens when 
you have multiple middle devices that do this lookup and a major traffic 
path shifts.  How many queries will a middle device generate?  Can a 
reflection attack cause those queries to be generated?  These are 
concerns that have to be addressed.

> In response I get vague handwaving about voice or video (I know from 
> personal experience that UDP-based NFS works fine in the face of an 
> initial packet delay of 10s of milliseconds) or descriptions about 
> classes of applications that would appear to be degenerate cases and 
> asymmetric routing that would likely have unpredictable performance 
You talk delay.  I talk loss.  Routers don't just keep packets lying 
around if they can't deliver them.

That could change, but again it's a tradeoff.  I haven't tested v3 UDP, 
but earlier versions of UDP NFS suffer from a 90% throughput loss in the 
face of as much as 1% packet loss.  This is a well known fact due to its 
backoff algorithm (I used to work for an NFS server vendor in an NFS 
environment with devices that dropped packets all the time - painful).  
I'll leave it as an exercise as to what happens with voice and video 
quality when packets don't get delivered.

My message to you: we need to understand the tradeoffs of pull systems 
and not pretend they will come for free.

Eliot

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 9 May 2007 10:14:05 -0700

Eliot, 

> the host, things get messy for the application (discussed 

When the device making the query isn't the host, but it is
*tightly-coupled* with the host, then it should be OK too.

Fred

---

From: Tony Li <[email-masked]>
Date: Wed, 9 May 2007 10:28:05 -0700

Dave,

> (hosts, firewalls, IDS's, enterprise inventory applications, etc.)

Understood, but perhaps I'm being unclear.  I'm referring to removing  
the *need* to renumber by making site addressing independent of the  
provider.  Specifically, if we do a locator/ID split properly and  
propagate it through the architecture, then filtering mechanisms can  
be done based on identifier and not locator.  Subsequent renumbering  
events then become cheaper.

This is a significant benefit to the site, and thus is a significant  
incentive to the host.

I should also note that this argument holds as long as the loc/ID  
mechanism has any functionality within the site.  If the LISP ITR/ETR  
is anywhere within the site, for example, this is relevant.

> from IPv6.

Correct.  That's what we're here to fix, in my perspective.  We need  
to change the network architecture and just changing the routing  
plane without a coordinated change from the hosts doesn't do that.

> Mobility incents _some_ hosts to change... but just the ones that are

I heard that something like 60% of all computers being sold today are  
laptops.  Given WiFi, EVDO, WiMax, etc., I would think that the host  
would want to make the best possible use of mobility.  And fixing 60%  
of the systems out there seems like incentive.

> correspondent nodes aren't strongly incented to change, and don't have

No argument, but it seems like the suboptimality introduced by the  
triangle routing problem might provide some encouragement to change  
the host.

Tony

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 10:47:34 -0700

At 9:39 AM -0700 5/9/07, David Conrad wrote:
>Yep.  You and others keep asserting that a pull-based mapping distribution model is a "non-starter" because it "won't work".  I've been trying to get from folks _concrete_ examples of applications that "won't work" in the face of increased latencies on the order of 10s or 100s of milliseconds after a cache miss.  In response I get vague handwaving about voice or video (I know from personal experience that UDP-based NFS works fine in the face of an initial packet delay of 10s of milliseconds) or descriptions about classes of applications that would appear to be degenerate cases and asymmetric routing that would likely have unpredictable performance characteristics with pull or push.
>
>GIven the lack of data, it would seem we've descended to the realm of religion, so I'll give it a rest.

Sorry, but I misunderstood you to be asking for what class of applications have
this problem, and my reply was intended to answer that:  those which do codec
negotiation based on observed rate.  Another class is those that use race conditions
to select flow endpoints (e.g. anything that will use ICE).  Not too many things
use ICE yet (still not standardized), but there are plenty in the former category.
Are you looking for something that has source code available, so you can see
what changes it would take to adjust the paradigm, or ubiquity, or what?

				Ted

---

From: Eliot Lear <[email-masked]>
Date: Wed, 09 May 2007 19:48:47 +0200

> *tightly-coupled* with the host, then it should be OK too.

Depending on the details, yes.  If you add signaling to the host, 
however, transition becomes "interesting".

Eliot

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 11:07:28 -0700

Ted,

On May 9, 2007, at 10:47 AM, Ted Hardie wrote:
> negotiation based on observed rate.

And how do those codec negotiations/ICE behave in the face of network  
congestion today?

> what changes it would take to adjust the paradigm, or ubiquity, or  

Pointers to source code would be nice.

I guess where I'm seeing a disconnect is in the fact that the  
Internet today is best effort, has congestion events, asymmetric  
routing and non-deterministic performance patterns.  If an  
application works today, I'm having trouble understanding how the  
introduction of additional O(10-100ms) latencies in the event of a  
cache miss (which will likely only occur at the first packet in a  
packet train) is going to have significant impact.  In those odd  
cases that there is an impact, how much work would it be to modify  
the application operation to be more tolerant of network delays?

Clearly, some believe that pull simply won't work.  I'm trying to  
understand why.  To be honest, it feels a bit like arguments I used  
to hear from Bellheads explaining why real production data  
communications could never work on datagram based networks...

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 11:37:17 -0700

Eliot,

On May 9, 2007, at 10:10 AM, Eliot Lear wrote:
> involved, for instance.  But when the device making the query  
> *isn't* the host, things get messy for the application (discussed  
> below).

There are numerous tradeoffs that have to be taken into account when  
choosing where to do the mapping.  The closer to the host you get,  
the less scope is affected by the mapping.  For example, if the  
mapping is done for a "site", changing the mapping has the effect of  
instantly changing the locator/ID mapping for all devices within the  
"site".  Move down to the host, and the change obviously only affects  
the one host.

> Then there are security and continuity considerations.

Agreed there are security considerations (I'm not sure what  
"continuity" considerations are).  There are security considerations  
in everything including both push and pull models of mapping  
distribution.

>> In response I get vague handwaving about voice or video (I know  
>> from personal experience that UDP-based NFS works fine in the face  
>> of an initial packet delay of 10s of milliseconds) or descriptions  
>> about classes of applications that would appear to be degenerate  
>> cases and asymmetric routing that would likely have unpredictable  
>> performance characteristics with pull or push.
> You talk delay.  I talk loss.  Routers don't just keep packets  
> lying around if they can't deliver them.

How does that ARP thing work again?

> That could change, but again it's a tradeoff.  I haven't tested v3  
> UDP, but earlier versions of UDP NFS suffer from a 90% throughput  
> loss in the face of as much as 1% packet loss.  This is a well  
> known fact due to its backoff algorithm (I used to work for an NFS  
> server vendor in an NFS environment with devices that dropped  
> packets all the time - painful).

I led the team that wrote one of the (if not the) first non-Sun-code  
derived NFS implementations using 3c501 cards on 8088 and 80286 IBM  
PCs.  I am painfully aware of UDP NFS behavior patterns, particularly  
in the face of packet loss and delays (the 3c501 card was  
"interesting", in the way the Ebola virus is "interesting").

It is probably worth noting that complaints about NFS's inability to  
cope with loss and delay led to the development of alternative  
protocols that were much better in dealing with non-LAN  
environments.  Which is sort of the point I'm trying to make.

> I'll leave it as an exercise as to what happens with voice and  
> video quality when packets don't get delivered.

Well, today, my video application pauses and says "buffering" and my  
voice app gets a bit of drop out (like talking on a cell phone).

Of course, this isn't really relevant as the only added delay in a  
pull model would occur primarily during the initial session  
initiation, e.g., when the domain name of the voice or video server  
was being looked up or the connection initiation packet was being sent.

> My message to you: we need to understand the tradeoffs of pull  
> systems and not pretend they will come for free.

This is a different statement than "non-starter" and one that I would  
agree with.  I'd also suggest that push systems come with tradeoffs  
that are not without cost (in particular, have much worse scaling and  
change propagation characteristics).  TANSTAAFL.

Rgds,
-drc

---

From: Ted Hardie <[email-masked]>
Date: Wed, 9 May 2007 12:14:53 -0700

At 11:07 AM -0700 5/9/07, David Conrad wrote:
>And how do those codec negotiations/ICE behave in the face of network congestion today?

For the codec negotiations, they downgrade or, as Marshall pointed out, they
may fail if only a single rate was supported.  For ICE, it will pick the flow
which returns successfully first.  I believe that this means that whether or
not a lookup is in cache will have a significant impact on which flow end points
are chosen in ICE.

For how do they work now, I think the key thing here is that they preusme congested
links will likely stay congested (or, depending on whether TCP's sawtoothing is
involved) may go from congested to uncongested and back during the
course of a flow.  In those conditions, a media stream using a UDP-based flow
*should* use a low-rate rate codec and should negotiate upward only
cautiously.  Otherwise its lack of congestion awareness is going to
be unfriendly to other flows.   Having a lookup delay at the start of the flow mimics
that congestion and produces sub-optimal results. 

I think the problem here may be that the lookup sounds like it is incurred
within the period of time that the application considers the flow to be
active and which it is using to gauge bitrate.  If the delay were entirely before the
flow were active (as it is for DNS lookups mapping the fqdn to a target
IP), then the clock would not have started ticking, so to speak, and this
delay would not have follow-on effects (it might add to existing frustration
at slow starts, but that is a different problem).  There may well be a way to
design that in at this point, but I think that works well only if the lookup
is at the host.  I may be missing something, of course.

>Pointers to source code would be nice.

pjsip has opensource stun, turn, and ICE; TIL has opensource ICE:

http://www.pjsip.org/download.htm
http://sourceforge.net/projects/til

The codec negotiation bits are a bit harder to point to, since
the rate adaptation code tends to be buried in a larger piece of
codec development.  Marshall may have a better suggestion, but
the videolan work, in particular on x264, may be useful.  That's
at:

http://www.videolan.org/developers/x264.html

>I guess where I'm seeing a disconnect is in the fact that the Internet today is best effort, has congestion events, asymmetric routing and non-deterministic performance patterns.  If an application works today, I'm having trouble understanding how the introduction of additional O(10-100ms) latencies in the event of a cache miss (which will likely only occur at the first packet in a packet train) is going to have significant impact.  In those odd cases that there is an impact, how much work would it be to modify the application operation to be more tolerant of network delays?

I believe that there are changes which could be made to overcome this.  One
obvious one is to have bitrate negotiation for codecs delayed until the impact
of this on the flow was no longer important ( easy enough if it is only the first packet
in the packet train), or allow for a single fast renegotiation, contrary to the usual
slow renegotiation.  So the amount of work is "some". 

But the bigger issue is that there is a class of applications which *wants* to know
about the network conditions and topology, so that they can modify their behavior
to handle it.  I don't think that is going away.  To me, that argues for including
the hosts in the set of network elements which at least MAY if not MUST participate
in understanding the locator/id split semantics and mechanics.  Or, to put it another
way, to participate in the routing system.

>Clearly, some believe that pull simply won't work.  I'm trying to understand why.  To be honest, it feels a bit like arguments I used to hear from Bellheads explaining why real production data communications could never work on datagram based networks...
>Rgds,
>-drc

			regards,
				Ted

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 9 May 2007 21:31:51 +0200

On Tue, May 08, 2007 at 01:16:58PM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 23 lines which said:

> the first packet?

The DNS? The first packet is often the last of a transaction. A lack
of reply because of mapping delay may seriously confuse, for instance,
BIND's best name server selection.

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 May 2007 14:05:10 -0800

On 2007-5-9, at 8:03, ext David Conrad wrote:
> the Internet is "best effort" and stuff happens to cause packet  
> loss or delay.  A pull-based mapping redistribution model implies  
> an increased amount of latency on cache misses (most likely on the  
> order of tens to hundreds of milliseconds, not seconds).  Internet  
> applications that I know of already must deal with variable  
> latencies of these orders of magnitude and I was asking for  
> pointers to applications that couldn't.

Don't forget that pretty much all our transport protocols work by  
gathering information about the transmission path (RTT, bandwidth,  
etc.) by running statistics over the packets they send. The  
assumption is that the path you'll send over in the near future will  
sort-of have similar characteristics to the one you have been sending  
over in the recent past. Anything that changes this assumption can  
potentially have negative impacts on the operation of our existing  
transport protocols.

(A well-documented example is the bad interactions between MobileIP  
and TCP across mobility events.)

More specifically, with LISP-like proposals and TCP, potential issues  
are things like a 3-second timeout if the first (SYN) packet is  
dropped. If the first packets take a different path, the issue is  
that the RTT and congestion window estimates won't describe  
conditions on the "final" path, which causes either inefficiencies or  
losses and then timeouts.

Lars

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 15:20:56 -0700

Lars,

On May 9, 2007, at 3:05 PM, Lars Eggert wrote:
> etc.) by running statistics over the packets they send.

Yes, but you left out the part about those protocols having  
mechanisms to detect and recover from connectivity degradation (e.g.,  
slow start).

However, this is largely irrelevant as in any rational pull-based  
mapping mechanism, the mapping information would be cached for all  
but the initial packet.

> More specifically, with LISP-like proposals and TCP, potential  
> issues are things like a 3-second timeout if the first (SYN) packet  
> is dropped.

I'll ask again:  how does this ARP thing work again?

Actually, I'll ask a different question:

People have been talking about having a push based mapping  
mechanism.  They have also been talking about having host-level  
granularity.  How is this going to work?  Are people imagining a  
flood protocol that propagates host-level mappings to every host on  
the Internet?

Thanks,
-drc

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 May 2007 14:30:46 -0800

On 2007-5-9, at 14:20, ext David Conrad wrote:
> mechanisms to detect and recover from connectivity degradation  
> (e.g., slow start).

I'm not saying that they will break - I am saying that there is a  
danger of additional inefficiencies.

> mapping mechanism, the mapping information would be cached for all  

That may be so, but it means that the behavior of the caching scheme  
will become important.

In any event, experimentation with the proposed schemes will  
hopefully result in a better understanding of what the effects are.

>> issues are things like a 3-second timeout if the first (SYN)  
>> packet is dropped.
>

First off, all the ARP implementations I know of queue the packet  
during the loopkup, i.e., no loss. Second, the duration of an ARP  
lookup vs. the end-to-end RTT is typically miniscule. This is not so  
with LISP-like schemes.

Lars

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 16:24:10 -0700

On May 9, 2007, at 12:31 PM, Stephane Bortzmeyer wrote:
> The DNS? The first packet is often the last of a transaction.

A good example.  The DNS is unusual for a lot of reasons.  That's why  
having the ITR also be the caching resolver is a good idea.

> A lack of reply because of mapping delay may seriously confuse, for  
> instance,

If you never go back to the name server, what does it matter if BIND  
is confused?  If you do go back, BIND will get revised RTT estimates.

(However, looking at the code in BIND9 (specifically, lib/dns/ 
resolver.c), I believe the resolver will try every 1/2 second the  
first two times before going into exponential backoff, arbitrarily  
setting the initial RTT to 200 ms in the event an RTT is not  
collected on the first attempt.)

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 9 May 2007 16:58:33 -0700

Lars,

> danger of additional inefficiencies.

Yep.  This is part of adding a layer of indirection implicit in the  
locator/ID split.

> during the loopkup, i.e., no loss.

That's what I thought, but folks have been saying that routers don't  
queue anymore.

> Second, the duration of an ARP lookup vs. the end-to-end RTT is  
> typically miniscule. This is not so with LISP-like schemes.

Yes, but memory for queues (for edge device I/O queues) is much  
cheaper than it was...

Rgds,
-drc

---

From: Lars Eggert <[email-masked]>
Date: Wed, 9 May 2007 16:43:47 -0800

On 2007-5-9, at 15:58, ext David Conrad wrote:
> That's what I thought, but folks have been saying that routers  
> don't queue anymore.

I'm only familiar with end-host ARP code.

> Yes, but memory for queues (for edge device I/O queues) is much  

I'm not worried about memory at all.

Whether a packet is queued while an ARP lookup is performed won't  
noticeably affect the end-to-end RTT that TCP measures, i.e., it  
won't affect TCP's RTT sampling. When LISP queues a packet while it  
does its magic, that is likely to take more time, because it's not a  
purely local operation, and this delay may influence TCP's RTT  
sampling, causing inefficiencies.

(When LISP forwards packets along a path with higher stretch during  
the setup phase, rather than queuing them, that may cause other  
inefficiencies, which I described in my first reply.)

Lars

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 May 2007 20:59:31 -0700

> That's what I thought, but folks have been saying that routers  

First, not all implementations.

Second what good is queuing the packet when you have two TCP  
connections starting out where the SYNs of each are going to the same  
default router you don't have an ARP entry for? That is, you lose the  
first packet from that connection's point of view.

There is so much chit-chat on a host before real work starts up that  
the ARP entry is already cached. And many implementations, when a  
interface comes up, sends a gratuitous ARP to announce itself and  
search for a duplicate address.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 9 May 2007 21:00:07 -0700

> I'm only familiar with end-host ARP code.

Routers are hosts too.

Dino

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 May 2007 07:07:20 +0200

> That's what I thought, but folks have been saying that routers don't 

Queuing is one thing.  By some definition, we could probably say that 
routers are really all just fancy queues.  But when the latency could be 
in the *seconds* for some destinations, that's no longer queuing.  
That's storage.  That's NOT what routers do today.  Also, please 
consider the problem in the aggregate when you bring a device into 
service.  How many queries must it make?  One?  Tens?  Hundreds?  
THOUSANDS?  If the device sits on the PE or CE (for large CEs), that 
latter number may be what we're talking about.

Eliot

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 May 2007 08:32:34 +0300 (EEST)

On Wed, 9 May 2007, David Conrad wrote:
>> First off, all the ARP implementations I know of queue the packet during 
>> the loopkup, i.e., no loss.
>
> That's what I thought, but folks have been saying that routers don't queue 
> anymore.

AFAIK, almost any router an operator would be willing to call a router 
deployed today start ARP (or ND) resolution process when a packet 
arrives that requires resolution.  The packet that initiated ARP/ND 
request is discarded, as are subsequent packets until the resolution 
is complete.

I understand queueing the triggering packets could be a DoS vector for 
networks where the target IP is down.

So, first-hit loss is not completely unheard-of in todays networks.

However, ARP/ND related loss only occurs per destination (and with 
usually long timers -- up to hours), not on (source, destination) 
basis.  That's why you very rarely see ARP-based packet loss even when 
starting communication with a new host.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: [email-masked]
Date: Thu, 10 May 2007 11:10:10 +0200

David,

> flood protocol that propagates host-level mappings to every host on 

I am the proponent of a BGP-based push mapping mechanism. In my
proposal on TIDR, I mention the possibility of propagating FEC
mappings that could even descend down to the TCP or UDP port level
per host. Obviously this is a nonsense nowadays. But, as almost
always, not all that can be done is eventually done.

I wanted to reflect in my proposal all the potentials of TIDR.
But this is similar to what currently happens with the use of
BGP for routing in the Internet: the BGP specification says
nothing about the maximum mask length that should be stored in
the RIB. It is the best current practice which dictates for
example that /24 is a reasonable limit. And this is achieved
by using filters.

Therefore an important feature of a flooding mechanism should
be the ability to differentiate the relative importance of
the objects being mapped so as to treat them differently by
means of filters of some type.

Someone mentioned some days ago that host-based solutions and
network-based solutions are orthogonal. I think he's right.

Regards,
Juanjo

---

From: Eliot Lear <[email-masked]>
Date: Thu, 10 May 2007 13:30:09 +0200

David Conrad wrote:
> choosing where to do the mapping.  The closer to the host you get, the 
> less scope is affected by the mapping.  For example, if the mapping is 
> done for a "site", changing the mapping has the effect of instantly 
> changing the locator/ID mapping for all devices within the "site".  
> Move down to the host, and the change obviously only affects the one 
> host.

Right.  And while it is perhaps inelegant in some eyes, there may yet be 
room for two separate approaches: one on the host and one off the host 
and somewhere in the network.  It may be possible to extend LISP into 
the host as well.  Clear functional separation may provide us with 
several approaches to deal with the mapping.  In an experimental 
environment that would be a good thing.
> in everything including both push and pull models of mapping 

Yes. Let's evaluate them.  When I say continuity, I mean, what happens 
when a router fails or comes into service.  Does its return to service 
mean that a bunch of name servers are about to be attacked?  Can it only 
but drop packets for the first few minutes because it needs to take the 
"suboptimal stretch"?  I'm talking about later versions of LISP here, 
for example, where there is no backup.

> How does that ARP thing work again?
ARP represents a millisecond delay.  Routers themselves ARP so rarely 
that it's not a factor.  What is a factor is when packets in the middle 
of a path are just dropped.

> was being looked up or the connection initiation packet was being sent.

You cannot say with certainty whether we're in session initiation or at 
some other point.  In the case of a routing transition, the new router 
will have to query to restart the connection, causing seconds of delay.  
The same will occur when things transition back, if either the old 
router has lost its cache or has been down sufficiently long for the 
cache to expire.  During this period of time the router would need to 
make as many queries (and maybe more) as it has conversations going on.

Eliot

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 May 2007 11:07:41 -0800

On 2007-5-9, at 19:59, ext Dino Farinacci wrote:
> connections starting out where the SYNs of each are going to the  
> same default router you don't have an ARP entry for? That is, you  
> lose the first packet from that connection's point of view.

That's a pretty unlikely scenario, but yes, the SYN of the second  
connection would get dropped and it would take a 3-second timeout.  
But the first one doesn't, which is the much more common case.

Lars

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 10 May 2007 12:10:12 -0700

> But the first one doesn't, which is the much more common case.

The point is these packet drops have gone unseen for decades. We  
shouldn't worry about solving problems like this. We have much bigger  
fish to fry.

Dino

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 May 2007 11:08:48 -0800

>> I'm only familiar with end-host ARP code.

OK, so to be crystal clear: I am only familiar with the ARP code on  
end-host operating systems.

Lars

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 May 2007 11:07:41 -0800

Lars

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 10 May 2007 15:34:14 -0500

I may be misunderstanding Lars, but I understood his point to be that, 
unless the host is opening two connections back-to-back, there is no ARP 
cache miss/queuing going on, and you don't normally lose the first packet of 
a TCP connection ("3 second timeout"), unless you're really seeing 
congestion (which is where you'd need to wait for a chile, anyway).

I understood his concern to be making sure we don't move from a network 
where we see 20-200 ms ARP cache timeout/queuing to a network where we see a 
3-second timeout at the beginning of every TCP connection. These would not 
be packet drops that have gone unseen for decades.

Thanks,

Spencer

>> connection would get dropped and it would take a 3-second timeout.  But 
>> the first one doesn't, which is the much more common case.
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 10 May 2007 17:07:29 -0800

On 2007-5-10, at 12:34, ext Spencer Dawkins wrote:
> I may be misunderstanding Lars, but I understood his point to be  
> that, unless the host is opening two connections back-to-back,  
> there is no ARP cache miss/queuing going on, and you don't normally  
> lose the first packet of a TCP connection ("3 second timeout"),  
> unless you're really seeing congestion (which is where you'd need  
> to wait for a chile, anyway).
>
> I understood his concern to be making sure we don't move from a  
> network where we see 20-200 ms ARP cache timeout/queuing to a  
> network where we see a 3-second timeout at the beginning of every  
> TCP connection. These would not be packet drops that have gone  
> unseen for decades.

Yup, I think we're on the same page here.

A very high-level summary of my concerns is that pull schemes can  
introduce variabilities (losses and/or delays) that can influence the  
operation of the end-to-end control loop that underlies most  
transport-level protocols. There is at least a potential for bad  
interactions.

We ran into this same issue with MobileIP, whose extensions to layer  
3 change the end-to-end path when handovers happen in a way that can  
make transport performance suck.

It would be very good to learn from this experience and make sure  
that we look into these issues during the design of new layer-3  
extensions - be it LISP or something else.

Lars

---

From: Gert Doering <[email-masked]>
Date: Fri, 18 May 2007 20:09:16 +0200

Hi,

> of the systems out there seems like incentive.

The question is "what do you gain by IP (host) mobility"?

I see "session survivalibility", which means "geeks can open an SSH 
connection to $somewhere, and their SSH will survive them roaming into
a different network".

OTOH: how many non-geeks have long-running TCP sessions anywhere, and
would even notice that they have kept their endpoint address?

Non-Geeks tend to do web surfing (short-lived), company VPN'ing (will
reconnect if the local address changes), e-mailing (short-lived, usually
accompanied by explicit authentication), and maybe voip (would need to
re-register, and the ongoing call is lost when actively walking around 
with your notebook pressed to your ear).

Mobile IPv6 aka "VoIP connections survive roaming about" sounds like
a good plan for when we have omnipresent IP connectivity without having
to manually login to all these different access points - but this is some
distant future, at least over here.  Which is why there might not be so
much demand...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Tony Li <[email-masked]>
Date: Fri, 18 May 2007 11:39:55 -0700

> The question is "what do you gain by IP (host) mobility"?

I would also consider solving the triangle routing problem as  
beneficial.

> with your notebook pressed to your ear).

I would expect that the last point alone should be significant to folks.

> distant future, at least over here.  Which is why there might not  

You can already wander around cities like Mountain View CA with WiFi  
connectivity.  When WiMax deploys, if even 50% of the hype comes  
true, this is going to become more common.  And EVDO is already doing  
this today.

Tony

---

From: Jari Arkko <[email-masked]>
Date: Sat, 19 May 2007 09:47:50 +0300

Gert, Tony,

>> distant future, at least over here.  Which is why there might not be so

This is indeed a significant problem. As long as the login process
is manual, all work stops until the user looks at the screen and
takes out his credit card or types a password. This applies equally
well to communications that could survive address changes
(Mobile IPv6, HIP, SIP, etc.) as any other communications, such
as polling your e-mail server for new messages.

There are many reasons for this situation both on the technical
and perhaps even more in the business side. Lack of a technical
solution is not the problem; we have some and we could easily
invent more. Its more of a question of how many solutions we
have, having a solution in all devices as opposed to just most
of them, suitability of solutions to the different business
models providers have, etc.

But I would suggest this is an orthogonal problem to discussing
routing scalability or even mobility. We know that we as the
industry must solve the network access problem, if we are
going to have gadgets that don't need continuous attention
from their owners and large screens to look at login pages.
Or $9.95 for every movement to a new administrative
domain...

> connectivity.  When WiMax deploys, if even 50% of the hype comes true,
> this is going to become more common.  And EVDO is already doing this
> today.

Or GPRS and UMTS. But you have to separate the the hype
about wide-spread connectivity of a particular access technology
and its effect to the network access problem. The problem is
not lack of wide-spread connectivity, but more in the use
of different networks. GPRS, UMTS, and perhaps
EVDO and later WIMAX are capable of serving you all over
the place. Each of these networks gives you an automatic
network access mechanisms. No typing, no web pages,
completely automatic. And even some of the movements
between these networks work automatically.

However, not all combinations can be made to work automatically.
More importantly, there are networks that do not use
the automatic means or do not have roaming with
your own provider. E.g., even if you do not need to
type anything in the new WIMAX network, you probably
still have to use your credit card or password
if you switch from WIMAX to a local WiFi network.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 May 2007 14:26:32 +0200

> if you switch from WIMAX to a local WiFi network.

And even if that gets solved, you will still need your
security credentials; it's increasingly less likely that a
random network will allow a random user in without credentials.

Are we really boiling that corner of the ocean here?

    Brian

-- 
NEW: Preferred email for non-IBM matters: [email-masked]

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 May 2007 17:22:05 +0300

Brian,

> random network will allow a random user in without credentials.

Right.

> Are we really boiling that corner of the ocean here?

No, we should not be. But if people have ideas
about this corner of the ocean, we could talk
about another effort. At the moment I'm not sure
what more we can do technically, however. If
there is something, contact me off the list and
we can talk.

Jari

---

From: Tony Li <[email-masked]>
Date: Tue, 22 May 2007 12:51:31 -0700

> there is something, contact me off the list and

I'm not an expert in this area, but isn't this type of thing already  
addressed by 802.1x?

Even if not, it's not hard to see the we will want to have automated  
authentication mechanisms that allow us to change networks without  
manual intervention.  So while we might not be there yet, this is a  
AAA problem that someone should go off and solve.  The network  
architecture itself should still allow for these transitions to be as  
seamless as possible, including session migration.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 May 2007 10:00:43 +0200

On 2007-05-22 21:51, Tony Li wrote:
> manual intervention.  

But if the authentication is done for an ID instead of a locator,
the AAA problem is somewhat transformed, I think.

> So while we might not be there yet, this is a AAA 
> problem that someone should go off and solve.  The network architecture 
> itself should still allow for these transitions to be as seamless as 
> possible, including session migration.

Indeed. Which, for real time apps, means that the latency for any
AAA handoff needs to be pretty small. And maybe basing it on an
invariant ID would help with that.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Wed, 23 May 2007 11:30:45 +0300

Brian, Tony,
>> I'm not an expert in this area, but isn't this type of thing already

Yes, and 802.11i, EAP, RADIUS, built-in facilities in
802.16 and [23]G* link layers, many different optimizations
of the various parts of the process, and so on.

>> So while we might not be there yet, this is a AAA problem that
>> someone should go off and solve.  The network architecture itself
>> should still allow for these transitions to be as seamless as

We need to be careful with the word identifier here. Currently,
network access is mostly based on either payment or subscriber
identity. But those identities are very different from IP layer
identifiers. Of course, the network access and IP layer setup
processes can be (and has been) tied together for optimization
reasons. Hopefully such optimizations do not create a 1-1
permanent binding between the subscriber identities and your
IP layer addressing or your future IP layer identifiers. This
would be bad for privacy reasons, for instance.

Jari

---

From: Leslie Daigle <[email-masked]>
Date: Wed, 23 May 2007 13:58:59 -0400

> would be bad for privacy reasons, for instance.

Exactly -- so let's turn the point around and say that the
routing & addressing effort has to look at this problem to the
extent of expressing requirements for, and developing to,
the network entity identifier.

If that gets implemented as a 1-1 binding between subscribers
and network devices, that's probably a bad choice, but is
(IMO) beyond the scope of this work.

Leslie.

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------