[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Requirements [was Re: Transport level multihoming]
- To: Joe Abley <jabley-ietf@automagic.org>
- Subject: Re: Requirements [was Re: Transport level multihoming]
- From: Daniel Senie <dts@senie.com>
- Date: Wed, 04 Apr 2001 13:45:52 -0400
- CC: multi6@ops.ietf.org
- Delivery-date: Wed, 04 Apr 2001 10:45:58 -0700
- Envelope-to: multi6-data@psg.com
- Organization: Amaranth Networks Inc.
Joe Abley wrote:
>
> On Wed, Apr 04, 2001 at 12:27:40PM -0400, Daniel Senie wrote:
> > > My answer is no, it would be a very serious mistake to require (b)
> > > in this case. It would result in an undeployable solution.
> >
> > Agree with Brian. Applications will have to deal with restarting
> > connections if they die. This is fairly common already, since the
> > IPv4/BGP multihoming world works this way.
>
> Could you explain this further?
>
> My impression is that IPv4/BGP multihoming that happens today provides
> session stability, and applications do not need to deal with restarting
> connections in the event of a re-homing event.
The reality today is that a TCP connection which is in place MAY survive
multihoming, but it only happens if conditions are right. What I see
frequently is the failover takes a significant amount of time. For a few
minutes, no packets get to/from a particular site that's affected. Once
the failover completes, any TCP connections which existed and were idle,
will probably be OK. Any that were actively being used (data transfer in
progress) usually hit platform timeouts at one end or the other. The
application or the TCP stack gives up after a number retrying a number
of times.
As a result, applications which are going to be robust and need to
maintain "permanent" connections over the network will need to know how
to re-establish those connections if there are problems.
So, in theory, TCP connections survive multihoming failovers. In
practice, it's not quite so robust.
>
> If the intention is to provide a multi-homing architecture in v6 that
> provides all the functionality of the v4 one, then I think we need to
> put more thought into why session stability is not required before we
> discard it. Otherwise there is a danger that pressure will exist to
> do CIDR-style multi-homing in v6 since it remains the only solution
> that meets this particular requirement.
I think we'll fail in the marketplace if the multihoming solution for
IPv6 isn't at least at the level of the present IPv4 solution. The
expectation will be there that we can do at least that much. Should we
do better? Perhaps. It's got to scale, while providing what the
customers want.
--
-----------------------------------------------------------------
Daniel Senie dts@senie.com
Amaranth Networks Inc. http://www.amaranth.com