RE: Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

About the goals of the multi-homing solution:

> > > The routing system seems to be good enough for this purpose
> > > when sites are not multihomed.
> >
> > Well, i am not sure about this.
> > Current studies of bgp convergence time are talking about up to 15
minutes
> > of BGP convergence when a route is withdrawn. Established communications
> > clearly don't survive this.
>
> OK, but fixing the BGP convergence time isn't in scope for this WG.
>
> My logic is to try to find where multihoming makes things different.
> The fact that BGP convergence time in the currrent Internet is worse than
> desired is something that should be addressed independently of
> multihoming,
> right?
>
> If not, shouldn't multihoming fix other pressing problems like
> world hunger?
>
> > Now, this is a requirement to the multi-homing solution. Moreover, it is
a
> > very difficult requirement. I mean, the goal of all this loc/id
separation
> > is the preservation of established communications, since most of the
> > remaining requirements don't need this and could be addressed with
> > alternative (more conventional) mechanisms.
>
> I would state the goal differently: taking advantage of the multiple
> attachments to the Internet to make the availability of the communication
> better than with a single Internet attachment.
>

The goal as stated in RFC 3582 is that:

3.1.6.  Transport-Layer Survivability

   Multihoming solutions should provide re-homing transparency for
   transport-layer sessions; i.e., exchange of data between devices on
   the multihomed site and devices elsewhere on the Internet may proceed
   with no greater interruption than that associated with the transient
   packet loss during the re-homing event.

   New transport-layer sessions should be able to be created following a
   re-homing event.

   Transport-layer sessions include those involving transport-layer
   protocols such as TCP, UDP and SCTP over IP.  Applications which
   communicate over raw IP and other network-layer protocols may also
   enjoy re-homing transparency.

So the question is: do current BGP responses times good enough to achieve
this goal?

IMHO, the problem is not whether we have to fix bgp or not, since i guess we
agree that don't have to fix it (or at least that it is not within the wg
scope)

I guess that the question is whehter we can base a solution that have to
provide transport layer suvivability on the current bgp capabilities.

Perhaps the answer is yes and there is no problem, maybe the answer is no
and we have to workaround and build a solution that don't use bgp.

The other point that you mention is that current non-multi-homed
communication already rely on bgp to be preserved through outages and so
that letting multi-homed communications rely on bgp for surviving outages
should be ok.
Well i don't fully agree with this pov.
We want to provide a solution that provides transport layer survivability,
that is the point of all this. Currently single homed communication probably
don't survive outages, even if there is an alternative path, becuase bgp
detection and reconvergence time is too long. We are providing a new
capability here, that is not available in non multi-homed communications.
So the tranport layer suvivability is one of the things that is different in
multi-homing, and in order to support this we may need not to base our
solution in bgp.


> Whether the result would be good enough to
>  - make the ftp connection stay alive
>  - make the user wait at the web browser or abandon and try another site
>   (order 10 seconds according to some studies I think)
>  - make VoIP survive without a click in the phone
> is a different aspect of the goal which we haven't talked much about.
>
Yes. we should discuss this. I would say that allowing the user to define
what he wants would be the best case... I mean, a solution that allows the
adaptation of the failure detection to need of the actual established
communication, what do you think?

I guess that the other relevant question would be what are the expected
capabilities in terms of response time for bgp in the IPv6 internet?

[...]
> Actually, in my mind but not in my writing, there are two subcases.
> 1) the ISP looses one peering and there is no alternate path to
> reach certain
>    destinations (due to the policy for the other peerings the ISP has)
>    If there are alternatives then the ISP can still reach all destinations
>    hence there is no observable failure.
> 2) the ISP looses peering(s) so that it can no longer reach any
> destination
>

I actually think that there is a middle ground situation where things are a
bit more complex
the following example for instance:

                     +---------+
                     |Internet |
                     +---------+
                       /     \
             outage-> =       \
                     /         \
                +---------+  +---------+
                |   ISP1  |  |  ISP2   |
                +---------+  +---------+
                  | |    |      |
     _____________| |    |      |
    /         ______|    |      |
   /         /           |      |
 +---+     +---+        +---------+
 |S1 | ... |Sn |        |  mhsite |
 +---+     +---+        +---------+

In this case, mhsite can reach all the customers of ISP1 through ISP1 and
all the rest through ISP2.
I have always considered the general case, where after an outage some
destiantions can only be reachable through one of the ISPs and a disjoint
set of destiantions can only be reached through the other isp.
Do you think we should start considering a simplified scenario?

> The second case can be handled without passing all routes to the site.
> How common is the first case?
> It depends on how the ISPs handle their own redundancy.
>
> I don't do operations thus I'd be interested in folks with operational
> experience commenting on the common and likely failures that a site should
> worry about.

Yes, i would like that too.

 What I've heard of are failures due to links being cut between
> sites and their ISP, backbone links back-hoed (but don't understand what
actual impact
> they had on each ISPs network), and ISPs going bankrupt.
>
> > Well, an option would be to have a cache of host that the node is
> > communicating with, so that it can ping them periodically until
> the cache
> > expires. The cache lifetime is extended everytime a packet from/to that
> > destiantion flows.
>
> Yes, but what is the lifetime of the cache entry after the last packet?
> How can you pick a value without knowing the actual behavior of the (UDP)
> application?

YEs this is complex, perhaps we could do something like an exponential
backoff? i guess that i would be more acceptable a delay when trying to
transmit after an interuption of a long period than interrupting a
communication that it is exchanging packets continiously, but that's just a
guess.

> Finally, any simulation data on how many peridical pings would be
> added to the Internet when everybody implements such a scheme?
>

No :-)
But i do have some simulation about how would the bgp detection mechanism
would affect an ongoing voip communication ;-)
Considering a sample every 20 msec, that would be 3000 samples lost.

> > Well, som additional cosndierations about this.
> > First, many existing ULP already exchange this type of
> messages, TCP ack for
> > instance, so hellos can be piggybacked into this messages.
>
> The TCP ssh connection I've had open for the last 4 days have not
> exchanged
> any packets as far as I know. (Well, perhaps there are the
> keepalive packets
> every 2 hours or so, but they wouldn't be sufficient to ensure that
> once I type something there is indeed a rapid response.)
>
> And we are not considering a TCP-only solution, are we?
>
>
> My take is that we should make the multihoming solution improve the
> availability of sites with multiple Internet attachments without
> requiring or
> assuming e2e periodic pings to quickly detect failures.
> Some applications/upper layer protocols might want to use such mechanisms
> in addition to the rehoming support in the multihoming solution
> for quicker
> failures (For instance, SCTP already has such a mechanism; heartbeats.)
> Thus I'm advocating not assuming that every ULP
> connection/session/assocatin
> has hearbeats when solving rehoming since we know of neither the
> performance
> implications of this on a large scale, nor the benefits that applications
> in general will derive from it.
>

I don't know.
My concern is that:

All the proposed solutions to preserve established communications require a
major update in the installed base, since they require modifications in both
nodes involved in a communication. (in brief big cost) Agree?

However,if we use bgp to detect outages, the benefit obtained will only be
partial, since the failure detection will take a long time in the general
case. This basically means that in multiple scenarios, established
communications will not be preserved. Agree?

Now if this is the cost and this is the benefit i don't know if this
solution is interesting. really high cost and reduced benefits.

Other arguments are that:

A loc/id solution provides a basic capability required to preserve
established communication, but the solution doesn't provide all what it is
needed. Additional stuff needed, such a failure detection mechanism will be
provided by the upper layer.
My answer to that is then why don't we just let the upper layer handle all
the problem then? I mean, you mention SCTP, well sctp provides heartbeat,
allright but it also manages multiple addresses in a connection, so the
loc/id solution doesn't provides anything useful to sctp. The same thing
could be done with TCP and also with application protocols

Another argument is that the loc/is split solution provides an high level
solution that can be also used to satisfy other needs, and not only for
multi-homing, so it should be adopted not becuase it is great for preserving
established communications in multi-homed environments, but because it is
architecturally sound. Well, i may agree with this, but in this case a wider
view is required to uderstand if such a solution is good for all other
requirements imposed, so we shouldn't be doing this in this wg (or only in
this wg at least)

BTW, if the argument to accept a solution is the last one, this would
discard solution without a strong loc/id separation that doesn't provides
good response times (noid for instance), right?



Regards, marcelo

>   Erik
>
>