[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: failure detection


El 18/08/2005, a las 17:06, Paul Jakma escribió:


...
Suppose you have a multihomed site with ISPA and ISPB and that they have assigned PrefA and PrefB respectivelly

Suppose you have Host1 in the multihomed host and that it is communicating with Host2 outside the multihomed site. For that communication, Host1 is using address PrefA:host1 both as locator and as ULID. I assume that host2 has a single address host1

Is host2 shim-aware? 

yes

It must be for scenario in next sentence to work. Particularly given RPF filtering at ISPs on "PA" customers.

Now, suppose that an outage in the link between the multihomed site and ISPA occurs. 

Ok.

Host1 detects and needs to do something about it, how can he try with an alternative path? 

Why must host1 detect this? Host2 could also ;).


not in a unidirectional connectivity scenario

consider the case where the failure implies that:
PrefA:Host1 -> Host2 is not working
PrefB:Host1 -> Host2 is working
Host2 -> PrefA:Host1 is working
Host2 -> PrefB:Host1 is not working

How would you cope with this case?

If, as part of shim6 control, host1 had, /in advance/, informed host2 that prefB:host1 was /also/ a valid locator, then:

- if host2 was first to detect the problem, it could simply switch to
  using the prefB:host1 locator

- if host1 notices there is a problem with bidirectional
  communication, it can simply start using the PrefB based locator
  (which host2 already knows about and should accept)


this last point is influencing SAS and trying with alternative source locators, which is basically what we are considering here and that you are opposing right?

This presumes host1 is actively managing its source address according to state specific to shim6. However, there is a *better* way:

- dont have shim6 pick the ISP dependent part of the locator
- let the OS's existing SAS mechanisms pick the source address
  according to routing policy, as per normal, for each and every
  packet
- let some external mechanism detect the local failure

Some (non-exhaustive) examples of such mechanisms:

- link status information

(eg PPP has its own heartbeat mechanism. PPP is often used for DSL connections, which will be a common case for the scenario described above for host1, today at least)

- Routing information

(eg, host1 /could/ get routing information from either or both of ISP1 and ISP2. Be it just a RIP default announced regularly on up to full *read-only* BGP feeds)

we have already discussed this point (in multi6) and imho it is not such a good idea to have the hosts to receive a full BGP feed.. i think there was ssome kind of concensous on this point, but maybe now has changed...


- Link probing / dead-gateway detection software

(At least one OS provides software to actively probe gateways and adjust routes as/when required)

- Well-known remote host probing software

And so on.

So, I'm not sure shim6 is at all the best place to take on detection of /local/ failures.


The idea is that shim performs e2e failure detection (as i already mentioned earlier) so that the fate of the communicating parties i.e. the apps is shared with the fault tolerance mechanism and that the shim can detect all the potential outages and recover from them. Having different mechanisms deal with different types of failures would result in a reduced protection i guess

Ie, in your scenario above, what I'm saying is:

- Shim6 on host1 doesnt and shouldn't be involved in detecting local
  failures


but you are assuming that host1 detects local failures through other means and this other means are likely to be injecting a full BGP feed into end hosts, right?

- Only host2 needs to know and detect whether it must use PrefA or
  PrefB based locator for host1.

Ie, this should all be about reachability of the *remote* locator. Which local locator to use should simply *not* be in scope for shim6 - then things get easier, and you can avail of one or more existing mechanisms for detecting local failures.


as i mention above, i am not sure if this supports the unidirectional case that i mention above.


...

This implies that in order to explore all the possible paths, we need to make n^2 probes.

Yes, if you refuse to consider the option of leaving SAS to something else (a wealth of mechanisms exist /already/), then you'll become convinced you need n^2 probes. :)

Now, it is important to realize that n^2 is just an upper bound, and that n^2 probes will only be performed when all paths have failed except one and this is the last one you have tried with

Even better is to realise that local address selection simply does not need to be something shim6 has to concern itself with. Then the number of probes, in the worst case, goes down to n, where n is the number of locators you have to hand for the remote shim6.

Don't forget, n^2 is per side. Each side will have to have to do it.
So you're looking at, worst case, for host1 with n locators and host2 with y locators, by my potentially incorrect algebra:

shim6 doing SAS and probing each side:

	y^2 + n^2

In the worse case, both y and n tend to infinity, so generally n = y, so the worst case therefore is:

	2*n^2

as n and y -> infinity.


Your math is correct
now let me ask: how many unidirectional address pairs are available between two hosts having y and n addresses each one?

i guess that we agree that there are y^2+n^2 different unidirectional address pairs, right?

So the point is: if you want to provide full fault tolerance you need to explore them all, if you don't, there may exists available paths that you are discarding, hence there are communications that could be preserved but you are not finding the available path to use.

Of course, you may have optimizations, like testing two unidirectional paths (one in each directions) with a single packet exchange (2 packets instead of 4), using local information for discarding some addresses and so on, but again these are only optimizations.

...

If you figure out that the local source to use is better left to other, existing, mechanisms, and only probe the remote side,
That's great, but you have 0 idea whether its the right address.

Determining the right address involves:

- route lookup on the destination to find the local output
- lookup source for this output

Shim6 /could/ do this, but on the other hand it could just leave the local address in packets sent down the stack as unspecified, and the OS will just do it for shim6.


how? i guess that you are asuming a BGP feed on hosts right?

I mean, a hosts with a single deafult route, wouldn't really know which of the n addresses available in its single interface to use for a given destiantion address... i mean DAS would not result in any particular address and the source address would be selected randomly...

What is the benefit for shim6 to do this, that it MUST? (It doesn't need to. Any such optimisations are purely implementation specific).

Ergo: No need for SAS in shim6.

No, shim will try to honor the policy table (or any other tool to express policy we need to define) Obviously, if the path preffered by the policy is not available, then shim will have to use others of course

See, there's an existing way to send a packet to a remote host and have the source be set appropriately for the preferred path - don't specify the source address...

No complications needed.

That's entirely scaleable and well within reason for deployment at 'enterprise' shim6 sites.

agree, but this is not enough to preserve established communications 

Why exactly?

Are you considering the case that full BGP feed is injected to the hosts, so that the hosts can find out which path is available towards its final destination?

Well, in a BGP fed and shimmed network, I would imagine the shimming would be done just on one or two hosts (or routers) at the edge of the shimmed network. The BGP feed would be confined to those.


well, this seems a bit far from what is currently being considered imho

So far, we are assuming that the shim is a host based approach and that each host performs all the functions of the shim

the case of the proxy that you are mentioning have been considered and it is attractive but it presents some difficulties, especially w.r.t security... perhaps you could try to consider the security implications of that split that you are considering...

As far as I know, the ULID and shimming host need not be same machine, is my understanding correct?

not sure what you mean here... ULID is upper layer identifier, right?
so the ULID belongs to the shim host, so i guess they are in the same machine

regards, marcelo