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

[Erik Nordmark <Erik.Nordmark@sun.com>]

> 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.

Perhaps the transport surviability statement in the goals document is a bit
off the mark.
Building a solution which assumes that routing basically works
i.e. only handling the fact that a multihomed site will have multiple
locators and need to have able to "rehome" communication between
those locators seems to make sense to me.
Assuming that routing is broken and making multi6 a general purpose overlay
which works over broken routing doesn't seem like a useful approach -
if routing doesn't work how can you reach the root DNS servers?
Oh - just reimplement DNS as part of the overlay. I think with those
assumptions you end up doing a complete overlay the same way that P2P systems
build a complete overlay (with their own directory, application layer routing,
etc)

But perhaps we started off the wrong foot here.

The concern you expressed was about BGP convergece time.
But if something happens in ISP A that will only affect traffic using 
the locator containing the A prefix. Thus the site doesn't need BGP to converge
about routing for A's prefix (which is the convergence time issue); the site
would just like to receive some indication from A (or detect that the link to
A is down) that something is not working well for A.  That could be sufficient
to have the site border routers start using the path through ISP B.

> 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 above is another case to consider.

> 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.

That is an interesting idea. But it doesn't actually provide transport
survivability.
For example, a TCP connection with TCP keepalive enabled and no data 
traffic exchanged for the last few hours expects a response in
a few minutes (the regular time). Same for using VoIP to listen
to a presentation - after having been quiet for 40 minutes I want to ask
a question and want the transmission of that question to be reliable.
Thus I think in general it isn't possible to infer how quickly failover needs
to  happen for a ULP based when the ULP last sent/received packets.

> 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?

I think you can do multihoming proxies so that a site can transition
to using multi6 even though the endnodes do not yet support it.
Basically the multi6 shim layer gets implemented in the proxy.

But yes, solving multihoming without changing code somewhere in the system
isn't feasible. No free lunch etc.

I think you must have incremental deployment i.e. allow a host or
site to introduce multihoming support and at least take advantage of that 
when communicating with other upgraded hosts/sites.

> 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?

I've seen papers on bgp convergence time. Are there studies on
the time it takes to infer that "something is problematic"
in bgp? ("something is problematic" might mean a lot of churn in the routing
table) If both ISPs pass their "bgp churn rate" to the site would that
be enough information to start using the other locator?

> 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.

That isn't what I've been saying. ULPs that have very specific time
constraints and are willing to pay the packet overhead, might want to consider
their own e2e heartbeats. The precense of these heartbeats will aid the multi6
layer to detect locator failures faster than the multi6 layer can do 
independently. 
But not all ULPs need such heartbeats.

> 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

Yes, but the number of such ULPs is larger than 1; with a common multi6 shim
you only need to build this in one place instead of N. With per-ULP
solutions your deployment concern doesn't go away.
So I don't see an argument for implementing this N times is better than
implementing it one time,

> 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?

Presumably this wider view would require that it there is a system which
can lookup identifiers e.g. to find the locators.
While one can speculate about such systems (see the future work section in
the SIM draft for an example of such speculation) with desirable properties,
it would take some time to understand what properties are needed,
design, and then deploy such a system.
And it isn't clear to me that there is sufficient impetus for such a system,
even if we had it all specified and implemented today, would actually get
deployed.

But in general I think whether this group decides to take the narrower 
multihoming view or the broader "id/loc separation in its own right"
view, it needs to be understood by the broader IETF community to
avoid any late surprises.

  Erik