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

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 10:20:02 -0500

William Herrin allegedly wrote on 11/21/2009 8:41 AM:
> On Wed, Nov 18, 2009 at 5:00 AM, Scott Brim <[email-masked]> wrote:
>> Excerpts from William Herrin on Mon, Nov 16, 2009 09:24:36PM -0500:
>>> 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.
>> 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.
> 
> Hi Scott,
> 
> That would be a host modification. 

Yes.  Hosts are being modified anyway, regardless of what RRG does or
does not do.  As long as routing scaling does not _depend_ on host
modification, it can _assume_ endpoint evolution in architectural planning.

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

That's what I was suggesting should be included in RRG's
"recommendation" to the IETF :-) -- a set of engineering boundaries the
IETF has to decide on.  There has already been lots of ad hoc
discussion.  In the end it's essentially decoupled.  The majority of
Internet endpoints will be mobile, and they cannot assume any particular
routing and addressing regime in whatever networks they connect to, so
they will take care of themselves.

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

Do you think routing and addressing requires a session ID in every
packet?  If not, let the upper layers find their own solutions -- e2e
argument and all that.

Scott

---

From: William Herrin <[email-masked]>
Date: Thu, 3 Dec 2009 15:29:41 -0500

Hi Scott,

Yes, I do think every packet needs a session ID, for much the same
reason that every packet has to have an IP address even if it's only
to a host on the local LAN that you could reach with only it's MAC
address. Any time the transport protocol relies on the IP address for
non-routing functions, it places a constraint on the structure of
routing system that isn't otherwise there.

Regards,
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: Thu, 03 Dec 2009 15:41:21 -0500

> routing system that isn't otherwise there.

I guess I should have phrased my question differently.  What I wanted to
stress was "Do you think ROUTING AND ADDRESSING requires a session ID"
etc.  That is, is this something that must be in a routing and
addressing architecture recommendation?

---

From: William Herrin <[email-masked]>
Date: Thu, 3 Dec 2009 15:52:11 -0500

> addressing architecture recommendation?

Scott,

Telling folks what *not* to do is at least as important as telling
them what to do, is it not? That's why the terminology has both a
"must" and a "must not." Telling folks to *stop* using the IP address
in the packet association process is very much a routing and
addressing architecture issue.

Regards,
Bill Herrin

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 03 Dec 2009 16:15:40 -0500

Part of my difficulty with the question is taht it presuppose that a 
system problem can be reasonably addressed by a compartmented 
recommendation.

If we could pretend that, then our recommendation would be "stop using 
PI addresses."  Of course we would ahve to include the codicil "Don't 
bother me with reality."

In purely technical terms, that suffices.  Obviously however, that is 
not a useful answer.  It may well be that a combination of stack 
identifiers (treated opaquely by routing and addressing), multipath TCP 
support, better Internet layer support for renumbering, and maybe a few 
other changes in other places, would actually be the right architectural 
end point.

And it may well be that we can create tunneling and other border 
techniques that will help get us there.
But for those to be the right answer it ought to be because in addition 
to solving short term problems, they help us get to the right long term 
answer.

Yours,
Joel

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

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:30:27 +0900

> routing system that isn't otherwise there.

What every packet has to carry is the node address(IP address), but not the
session ID. Session ID is a property of the layer up. In the current
Internet model, socket could be considered as session ID, which, however,
need not be visible in the packet header where the main job is routing.

(Somebody told that socket is not enough to distinguish a session. Perhaps,
he is right. I have thought about this too deep.)

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 16:34:35 -0500

> system problem can be reasonably addressed by a compartmented

No.  I'm saying that routing doesn't care about identification
functions.  Beyond that, there is the question of how to put the
architecture of the Internet together, including all layers.  That is
particularly not in the RRG's scope.

What I would like to see in an RRG recommendation would be: In recent
years the network layer has taken up the slack for architectural
shortcomings in other layers, because we were good at doing so.  At this
time (1) this burden is heavy on the neck of routing and addressing, and
(2) architecture is being reviewed and revised at all layers.  It's an
excellent opportunity.  From the point of view of the RRG, there are
certain things which the IETF must do, particularly

  - Stop identification functions from using topology-dependent
    information in order to make selection of a robust, flexible routing
    and addressing architecture easier.

  - (Insert other MUSTs here.)

Beyond that, the RRG recommends that the IETF explicitly decide how much
the IETF wants to adjust upper layer architecture and how much the IETF
wants to routing and addressing to compensate for lack of architectural
correctness in the upper layers.  This will affect how the routing and
addressing architecture evolves.

See?

Scott

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:36:40 +0900

> he is right. I have thought about this too deep.)

Perhaps, I should have said 'port-id' instead of 'socket.'

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:37:45 +0900

> addressing architecture recommendation?

I believe not. Session ID should reside somewhere between the Transport and
the Application layer. (And I think what people mean by session here is
something that doesn't break even if the transport connection breaks
temporarily.) And I'm not sure whether current port-id is enough for the
purpose of session ID. Or we need combination of port-id and socket to come
up with a meaningful session ID.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: William Herrin <[email-masked]>
Date: Thu, 3 Dec 2009 16:43:30 -0500

> need not be visible in the packet header where the main job is routing.

DY,

The consequence of that choice is a constraint on the routing system:
because the socket's ID isn't carried in the packet, the IP addresses
carried in the packet must match what the transport protocol expects
or the packet can't be associated with the correct socket. If an
identity for the socket was explicitly included in the packet, that
association function would operate independent of the IP addresses
present... Just as IP routing operates independent of the MAC
addresses attached to the packet.

On Thu, Dec 3, 2009 at 4:34 PM, Scott Brim <[email-masked]> wrote:
> functions.

Scott,

To the extent that the identification functions place constraints on
the operation of the routing system, it cares very much. Or if you
want to look at it from the other side: the routing architecture
places constraints on the permissible identification functions and
those constraints have to be adequately specified.

Regards,
Bill Herrin

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:45:03 +0900

> addressing architecture evolves.

An excellent point.

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Dae Young KIM <[email-masked]>
Date: Fri, 4 Dec 2009 06:50:41 +0900

> addresses attached to the packet.

Oh, here, we're misunderstanding each other.

Sure, the session ID should be somewhere deep in the data part of the
packet. But what I meant to say was that this session ID need not be visible
at the network layer who's function is routing. All network layer needs, or
should work on, is the network address (or in my term node address.)

-- 
Regards,

DY
http://cnu.kr/~dykim

---

From: Scott Brim <[email-masked]>
Date: Thu, 03 Dec 2009 16:51:21 -0500

William Herrin allegedly wrote on 12/03/2009 4:43 PM:
> the operation of the routing system, it cares very much. 

Right.  See later mail.

> Or if you

I do not expect that our routing choices will place serious constraints
on what identifiers would work.  Identifier usage is by nature a matter
for endpoints and supporting infrastructure services.