Subject: RE: IETF multihoming powder: just add IPv6 and stir

From: "Christian Huitema" <[email-masked]>
Date: Fri, 2 May 2003 13:08:49 -0700

> > I am not sure I want to say that we recharter to the GSE++ model. I
> > think we need to recharter mainly to update the milestones and also
to
> > perhaps change the charter somewhat.
> 
> Ok, the charter isn't the most important thing, what we want to
> accomplish is.

Frankly, I don't believe that there is all that much value in the
so-called "GSE++" model. I see many shortfalls:

1) Rewriting addresses in the site exit routers deprives smart hosts
from the capacity to select their preferred return path;

2) There is a lot of ambiguity as to whether the proposed identifiers
relate to an interface, a host or a session, and these choices lead to
extremely different trade-offs;

3) We know from previous discussion that 64 bits is too short for a
randomly assigned global space;

4) It is kind of too late to rewrite the TCP implementations that are
already out there.

In fact, if we really want to go towards this independent identifier
path, I believe we should make it a session identifier, used by some
form of TCP++. Using it for routing does not appear all that practical.

-- Christian Huitema

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 3 May 2003 03:55:54 +0200

On vrijdag, mei 2, 2003, at 22:08 Europe/Amsterdam, Christian Huitema 

> from the capacity to select their preferred return path;

If I get to multihome but I don't get much say in my return path that's 
a sacrifice I'm willing to make. However, this is a valid concern so we 
should see if we can do something about this.

> extremely different trade-offs;

Can you elaborate? I'd prefer the network to be agnostic about the 
meaning of identifiers, this is something the hosts can work out for 
themselves.

> randomly assigned global space;

That's why we have the ++ part in GSE++.  :-)  I want to make this such 
that the identifier can be a full 128 bit IPv6 address if desired.

> 4) It is kind of too late to rewrite the TCP implementations that are

That's why we want proxy multihoming agents that can handle all the 
multihoming processing so there is no need to upgrade existing v6 
implementations immediately.

> form of TCP++. Using it for routing does not appear all that practical.

If we get the GSE++ right, it should provide much of the groundwork for 
upgrading TCP. What do you mean by a "session identifier"?

---

From: David Conrad <[email-masked]>
Date: Fri, 2 May 2003 16:22:54 -0700

Christian,

> from the capacity to select their preferred return path;

To be sure I understand, you are saying that my laptop should have the 
ability to make a decision as to what ISP Microsoft uses to route 
packets back to me?

> extremely different trade-offs;

In the model I've tried to describe, everything from bit 48 to 127 is 
handled identically as it is handled in the existing IPv6 
specifications.  Are you indicating those specifications have ambiguity 
and that a specification for multi-homing should remove that ambiguity?

> randomly assigned global space;

Sorry, must have missed this suggestion.  Where would a random 64 bits 
be used?

> 4) It is kind of too late to rewrite the TCP implementations that are

In the model I've tried to describe, existing host IPv6 stacks would 
require no changes whatsoever.

> form of TCP++.

While I think TCP++ would be a lovely idea, I don't believe it is 
realistic unless it incorporates backwards compatibility and if it 
incorporates backwards compatibility, I don't see how you can get 
multi-homing without either NAT or rewriting.

> Using it for routing does not appear all that practical.

Eye of the beholder, I guess.

Rgds,
-drc

---

From: Peter Tattam <[email-masked]>
Date: Sat, 3 May 2003 12:31:51 +1000 (EST)

Hmm.  I really don't want to add fuel to the fire on these issues, but I feel
that it is important to respond to these criticisms because I don't agree with
the analysis.  See the end of the messag for some further comments.

> from the capacity to select their preferred return path;

I proposed that this only need be done for hosts which are not MH aware.

> extremely different trade-offs;

I don't know what you mean by this.  I thought they referred to whole sites.

> randomly assigned global space;

I thought we were talking about a M + S + 64 bits address space where the M
bits can be guaranteed globally unique and the S bits are managed by the site. 
For the purposes of global routing, this is unique enough to guarantee no
collisions.  The uniqueness of the 64 bits within the local segment are managed
by existing mechanisms of address autoconfig.

> 4) It is kind of too late to rewrite the TCP implementations that are

Yes, but such a proposal can work with mixed TCP implementations.  The only
difference between the two is whether to modify addresses at the edge or in the
stack.  I'm sure there must be a way to arrange it so that the end hosts can
choose to do the translation themselves.

> form of TCP++. Using it for routing does not appear all that practical.

I might add an out of band comment about the political issues surround this
whole MH debate.

I am agnostic about which proposal(s) make it and at the end of the day will
support whatever proposal is chosen.  I haven't got the time (I have plenty of
other work to do) or money (can't afford to go to IETF meetings) to be an
activist for any particular proposal and I don't need the karma points for my
career.  All I care about is whether in 10 or 20 years time that whatever's in
place will work well and history will show that the right decision was made.

It's for these very reasons that I haven't invested a great amount of time into
a formal proposal that everyone can pull apart.  I am happy to throw ideas into
the arena and chew them over, but until a firm direction is established and
there is overwhelming support for that direction I'm reluctant to spend any
more time than is necessary on the debate. 

Regards

Peter
--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 3 May 2003 14:17:11 +0200

> ability to make a decision as to what ISP Microsoft uses to route 

Just because that's the way it's done today doesn't mean it has to 
continue to be done like that in the future. Consider:

  +-- ISP B --- ISP C --+
DC         \ /         |
  |         / \         MS
  +-- ISP A --- ISP D --+

This makes for four possible paths from you to Microsoft:

DC -> B -> C -> MS
DC -> B -> D -> MS
DC -> A -> C -> MS
DC -> A -> D -> MS

Conversely, there are four paths back. If we get to choose paths on a 
per-session basis, this makes for no less than sixteen possible 
permutations. (Of course this assumes transport sessions don't care 
about the source and/or destination addresses.)

This makes for an interesting problem. On the one hand, we want to be 
able to take advantage of whathever capacity is available. On the other 
hand, managing n^2*m^2 paths (where n and m are the number of 
ISPs/addresses on each end) isn't an attractive proposition.

> multi-homing without either NAT or rewriting.

I don't see much of a problem here. In order to be compatible, the 
first packet must comply with existing TCP semantics but in a way that 
signals that the session initiator supports the ++ extensions. Then 
either the receiver answers with a regular SYN/ACK and we do regular 
TCP, or the receiver answers with a TCP++ session init packet and we 
don't have to be compatible any more. (Middleboxes won't like this, 
though.)

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 4 May 2003 13:28:15 +0200

> so-called "GSE++" model. I see many shortfalls:

There are shortfalls with all the solutions. As Iljitsch noted, this 
does not have to mean that we depreciate all the others.

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 05 May 2003 09:05:57 +0200

Peter Tattam wrote:
...
> by existing mechanisms of address autoconfig.

That isn't the only requirement. If the M is mutable and the S has no 
particular reason to be unique, then if you have a set of peers 
intercommunicating, you've only got the 64 bit IDs available to act as 
unique IDs for transport end-point and security end-point identification.

So there is a strong requirement that the 64 bit IDs be unique within
any set of intercommunicating peers. (In the case of TCP, the set has
two members; in the case of FTP it's any number, by use of the PORT
command.) 

   Brian

---

From: David Conrad <[email-masked]>
Date: Mon, 5 May 2003 12:55:33 -0700

Brian,

>> bits can be guaranteed globally unique and the S bits are managed by 

Or, more specifically, S+64.

>> by existing mechanisms of address autoconfig.

Right.

> unique IDs for transport end-point and security end-point 

Not unless M is globally unique.

> two members; in the case of FTP it's any number, by use of the PORT

No.

All the GSE-like solutions discussed to date that I am aware of have 
assumed the first 48 bits (the locator) are globally unique.  This is 
sort of fundamental.  If the first 48 bits are unique, then the last 80 
bits may or may not be unique depending on what you want to do.

Rgds,
-drc