I don't think the two are inherently that different. Say you define a new
identifier that can be associated with a connection endpoint, and you build
a mechanism that allows a host to map that identifier to one or more
locators. Now you can tweak TCP to allow it to define either or both of its
connection endpoints (what is now the pseudo-header) in terms of those
identifiers rather than in terms of the locators currently in use, and you
tweak the demux layer on hosts that support this extension so that it can
accept multiple source,destination locator pairs and map each of them into
the same TCP channel that is defined in terms of endpoint identifiers.
Then you define ways of doing signalling via TCP options so that the hosts
can learn about new locators and deprecated locators for their peers. I
see this as a variant of your #2, but it also has a vague resemblance to
NAT.
mucking the IP header is bad.. if we could reach some solution that is NOT
mucking the IP header then it might be ok...
In my mind the IP header still contains the addresses of the locators in use,
and layer 3 (at least that part of it) works entirely the same as it does now.
But the TCP pseudo-header might contain different identifers than those
addresses, and as far as TCP is concerned the (source address, source port,
destination address, destination port) would no longer necessairly be the
connection identifier - there would be a mapping function between those and
the real connection identifier, which would be defined in terms of endpoint
identifiers and ports.
ok.. but I think you are really talking about a "new" TCP...
If it turns out to be feasible, there's a lot that can be leveraged by making
mods to TCP rather than moving to SCTP or some other protocol. In particular,
you can ease transition (one end could be running new TCP and the other old
TCP and they could still talk as long as neither end moved) and minimize the
mods to existing apps. And it may be easier to get host stacks to implement a
TCP exstension than to implement a new protocol, even assuming similar amounts
of code for each.
and of course neither SCTP or TCP would be sufficient by itself. we still
need a suitable identifier, a way to map those into locators, and a way to
maintain those mappings.
I'm still undecided about whether it is better to modify existing transports
or to do a mobile-IP like approach. The latter has tunneling overhead but
works for all transports and in some sense the changes are simpler.