Subject: Re: [rrg] moving towards recommendation: the current plan

From: [email-masked] (Noel Chiappa)
Date: Mon, 16 Nov 2009 20:37:59 -0500 (EST)

> From: Michael Menth <[email-masked]>

    > it touches a fundamental problem of Loc/ID split solutions based on
    > address rewriting when hosts have only a single local address but their
    > edge network is multhomed to the outside world.

I'm not sure I understand what the problem is; can you explain in a little
more detail?

	Noel

---

From: William Herrin <[email-masked]>
Date: Mon, 16 Nov 2009 21:24:36 -0500

On Mon, Nov 16, 2009 at 8:37 PM, Noel Chiappa <[email-masked]> wrote:
>    > From: Michael Menth <[email-masked]>
>
>    > it touches a fundamental problem of Loc/ID split solutions based on
>    > address rewriting when hosts have only a single local address but their
>    > edge network is multhomed to the outside world.
>

Hi Noel,

A is a client talking to a multihomed server B.

Ip addresses:
A: 1
B: 2 (internal) 3, 4 (external)

Round trip from A to B:
A picks address 3 via DNS.
A->(1,3)->(1,2)->B->(2,1)->[(3,1),(4,1)]->A

The problem is that A received a return packet from B that might have
been from 3 and might have been from 4. But A has no idea what to do
with a packet from 4.

Per Michael, the solution is either:

1. Stateful NAT. The translator on B's network handles both network
paths and remembers that the communication from A came to destination
3 so that he can put source 3 back on the outbound packet.

2. Host modification. The inbound NAT adds an IP extension with the
original destination address. The host echos this in the return
packet, providing the outbound NAT with the info he needs to set the
correct external source address.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked]  [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: [email-masked] (Noel Chiappa)
Date: Mon, 16 Nov 2009 22:29:40 -0500 (EST)

> From: William Herrin <[email-masked]>

    >>> a fundamental problem of Loc/ID split solutions based on address
    >>> rewriting when hosts have only a single local address but their edge
    >>> network is multhomed to the outside world.

    > been from 3 and might have been from 4. But A has no idea what to do

Ah, got it. Hence the reference to "based on address rewriting", in the
original message. Since I'm mostly thinking in a 'wrapping' world these days,
I'm unfamiliar with these problems... :-)

The wrapping has the benefit of allowing one to not have to discard
information (which one has to when one doesn't have enough fields at hand to
hold them all); one can keep the original identifier, and have the locator
too. (Which is fundamentally the problem above - trying to put the proverbial
10 pounds in a single 5-pound field...)

    > 1. Stateful NAT. ... so that [it] can put source 3 back on the outbound packet.
    > 2. Host modification. ... The host echos this in the return packet

Well, the second is clearly infeasible. The first isn't so hot either.

Which leads me, in the context of Tony's earlier observation (that the RG
more or less unanimously now holds that separation of location and identity
is a crucial underlying piece of foundation for solving the routing
scalability issue), to a proposition...

I wonder if we can say that, at an architectural level, wrapping solutions -
or, more generally, any solutions which carry both the locator and the
identifier in the packets - are inherently and inescapably superior? This
seems fairly logical, to me: clearly, if one can't carry both locator and
identifier, one has to throw one away; and having done that, there are almost
inevitably going to be problems caused by cases where one needs whichever one
of the two one no longer has...

	Noel

---

From: Michael Menth <[email-masked]>
Date: Tue, 17 Nov 2009 07:48:13 +0100

Hi Noel,

> of the two one no longer has...
We also discovered that issue. Probably we can say, it's hard to combine 
the following three things:
1. Multihoming
2. Active multipath routing by the host
3. Local addresses hiding information about global locators which makes 
renumbering easier.

Regards,

    Michael

> 	Noel
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>   

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 17 Nov 2009 02:02:30 -0500

Yes.  That was the point of my comment at the mike in the session.
I like some of the soltuions that do host based handling, in part 
because they allow for things like multipath TCP.

But, if we are going to do that, we are going to have to actually make 
renumbering a LOT easier.  We are going to have to address the issues in 
Brian Carpenter's draft.  I believe that some of the issues will 
themselves be made easier by the separation of identifiers from 
locators.  But it will take more work than that.

Yours,
Joel

Michael Menth wrote:
...

---

From: Scott Brim <[email-masked]>
Date: Tue, 17 Nov 2009 16:26:02 +0800

> because they allow for things like multipath TCP.

You're going to get this in any case, for free :-).  An endpoint cannot
assume that a network it is connected to has a particular technology
(such as GSE), so it needs to take care of its own multihoming/mobility
needs.  No matter what happens in routing, endpoints are going to move
toward true location/identification separation.  This relieves the
pressure on RRG and opens up opportunities.

> locators.  But it will take more work than that.

Endpoints are easier than sites.

swb

---

From: Scott Brim <[email-masked]>
Date: Wed, 18 Nov 2009 04:00:52 -0600

Excerpts from William Herrin on Mon, Nov 16, 2009 09:24:36PM -0500:
> The problem is that A received a return packet from B that might
> have been from 3 and might have been from 4. But A has no idea what
> to do with a packet from 4.
> 
> paths and remembers that the communication from A came to
> destination 3 so that he can put source 3 back on the outbound
> packet.
> 

Another possibility is to decouple establishment of higher layer state
from the IP locators the packets come tagged with.  

For example, if they are using TCP and the correct tokens are provided
with SYN etc., then the result of having packets sourced from
"unexpected" locators is that endpoints learn new locators that could
be used for the session -- not that the session can't be initiated.

In general, a number of the problems that routing and addressing face
simply go away if the endpoints are told that it's the new millennium
and it's time they acted like adults.  Endpoints will need to be able
to do this anyway, since no matter what you do in particular networks,
the endpoints may always end up in a situation where they have to take
care of themselves.  As long as we're doing long-term architecture (in
the rRg), let's set a goal of solving problems where the roots of the
problems are.  Then we work back from that to provide interim bandaids
for curdmudgeonly old endpoints that don't know how to use the new
Internet yet.

Excerpts from Noel Chiappa on Mon, Nov 16, 2009 10:29:40PM -0500:
> Well, the second is clearly infeasible. 

It's infeasible because it once again carries locators as payload.
The NATs shall always be with you.  An endpoint should assume that
what it sees of locators may be totally different from what its
correspondent sees.

> I wonder if we can say that, at an architectural level, wrapping
> solutions - or, more generally, any solutions which carry both the
> locator and the identifier in the packets - are inherently and
> inescapably superior? 

No :-).  Any solution which separates identification from location is
superior, but there is no need to carry node-level identifiers in any
packet at all.  Who benefits from that?  Routing and location don't
care -- they only benefit from a whole-node identifier if they are
trying to solve problems that have been laid on them by the laziness
of higher layer functions.  Endpoints have all sorts of identification
functions, but a whole-node identifier does not satisfy all of them,
nor can it alone be used by any of them.

Scott

---

From: William Herrin <[email-masked]>
Date: Sat, 21 Nov 2009 08:41:16 -0500

> be used for the session -- not that the session can't be initiated.

Hi Scott,

That would be a host modification. Speaking of which, has anyone in
this WG considered setting aside the great debate about architectures
long enough to try to compose some consensus recommendations targetted
at the Multipath TCP working group stating what exactly the routing
folks would like to see them achieve? If we'd like them to carry a
decoupled session ID in every packet and deal with it successfully
when the IP address for a particular flow changes unexpectedly, we
might want to mention that before they finish.

Regards,
Bill Herrin