Subject: RE: ISP failures and site multihoming [Re: Enforcing unreachability of site local addresses]

From: "Bound, Jim" <[email-masked]>
Date: Fri, 21 Feb 2003 12:47:39 -0500

Folks,

I am on multi6 and just listen and send clarification questions to
various participants.  But a short comment here.

> Has the end-to-end principle failed to teach us anything? 
> Reliability begins and ends in the end hosts. If each host is 
> connected over two service providers there are four possible 
> paths the hosts can switch between on a per-packet basis. 
> Then the only problem becomes detecting failure. The end 
> hosts are in an excellent position to do this without having 
> to generate keepalive messages; a well designed protocol 
> could switch to an alternate path within a few round trip 
> times when a path failure occurs.

I agree with the above view and much of the problem can be solved by
intelligent code and configuration being done by the end system for new
IPv6 development and some existing network application infrastructure
that is a direct port from IPv4 that has been ported and deployed.  SCTP
is a clear winner for us here over TCP and it's a new API so we could go
there.  But more importantly the transition to this requires code on the
end systems from suppliers, and then either apps change or shims are
built on the end systems. Doing it with TCP is possible till SCTP is
more dominant.  This is solving the problem at layer 7 and 4. And that
means we need new platform code releases and development to make it
happen.  Which is fine but will take time.

Layer 1 and 3 may be able to do something too but that will take time
and require new code and platform releases.

I think we need to first pick which way we want to specify this or both
and provide technical spec on what each mean.

It is really transparent to IPv6 but IPv6 has a better chance of getting
this right.  

> Multi6 has been gravitating towards multi-address multihoming 
> solutions for a while now, but unfortunately it seems 
> impossible to move foward.

Hmmm.  At some point this needs to get done folks.  Not sure what will
cause it, but I believe it may be external forces resolve it for us.

P.S. Mutli6 should not MUST SCTP as Diameter tried (well was forced)
that and all the Diameter products shipping are doing it with TCP and
same for some other things like RDMA. But Multi6 could do the community
a big favor by stressing that SCTP really helps this problem within its
inherent failover capabilities via the network association for the
connections.

Regards,
/jim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 22 Feb 2003 01:49:29 +0100 (CET)

On Fri, 21 Feb 2003, Bound, Jim wrote:

> SCTP

> and require new code and platform releases.

Well, the "let's do it fast" ship has sailed a long time ago (it is
presumed to have hit an iceberg). So we only have the choice to do it
right or not.

It's time we start to rethink what we're trying to do here. Sure, SCTP
will provide some functionality. HIP also. Add a header here, a tunnel
there, maybe a little aggregation... It will all help with the problem
at hand to a certain degree, but it will break nearly as much as it will
fix and in 10 years we'll be doing it all again for IPv7 or OSIv3.

The problem with the IPv4->IPv6 transition is that all applications have
to change. That sucks. So what is it we do? We replace the socket API
that sucks with an API that sucks with bigger addresses. If we're going
to do SCTP, we'll be replacing the API with one that sucks with multiple
addresses. (I'm not about to apologize for saying the socket API sucks,
I've programmed with it.)

If we're going to change applications, we need to do it in such a way
that we won't have to do it again. So regular applications such as
remote login, email or webbrowsing only get to see the information about
a connection that they must, by their nature, always be able to parse.
That would be a hostname. Or an email address. Or maybe even an X.509
certificate. But NOT the plumbing, because we'll want to change that
later as new technology becomes available, WITHOUT having to change our
apps again.

If we can agree on this and recognize the fact that changing the IPv6
packet format and routing paradigm at this stage is counterproductive,
the rest should be easy.

> inherent failover capabilities via the network association for the

No idea what you're referring to here.