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

Re: survivability, rewriting

On 1 nov 2003, at 20:07, marcelo bagnulo wrote:

Also, it
might be beneficial to find out which alternatives still work before
selecting them to continue the session over.

Ok, but wouldn't this delay the reovery? i.e. the response time would be
worse

That is a possibility, but on the other hand rehoming in the blind also has its risks. For instance, if an upper layer protocol provides too many hints, we could be rehoming when there was just some incidental packet loss. I'm pretty sure rehoming will have to trigger slow start in TCP, which is not something you want to happen if isn't absolutely necessary. Or, in the case of a relatively large number of possible paths, several paths may share some infrastructure and go down at the same time. In that case, checking all paths helps avoid choosing a backup path that is also down. If we indeed go for the ping bomb approach there is the advantage that we immediately see which path is fastest, which is also a good feature and it only takes a single round trip.

Yes. But I don't think we want to do this with actual data packets. In
fact, there may not be any data packets available when this is
triggered by a hint.

I can think of two types of hints:
- a first type where the sending endpoint timeouts, so it detects the
failure by itself. This is the case where ack are used such as tcp. In this
case the ULP of the endpoint that is sending hints the M6 layer of the
sending endpoint (this is the easy case, i guess)

- a second type where no ack are used, so the ones that detects the failure
is the receiving end who detects the failure because it no longer receives
packets at the expected rate. In this case, the receiving end has to
communicate the problem to the sending endpoint. So in this case, the ULP of
the receiving endpoint has to hint the M6 layer of the sending endpoint.

Hm, doesn't the other side determine that something is wrong because it doesn't see any acks? If the ULP supports nacks then the receiving end can send those to get the message across sooner.

Does thus makes sense? can you think of other scenarios?

Another possibility would be that a receiver sees consistent duplicate packets, which indicates that the acks aren't getting back to the sender.

We may also want to trigger re-evaluation of reachability in some other cases. For instance, when a session has been idle for a long time, or upon some kind of hardware or routing event.

Then in the first case, the sending enpoint always has packets, since it has
detected the failure because of retransmissions, i guess. So, why don't you
think it should not try every possible path with data packets?

Might be an implementation issue. Might not be a problem, though.

In the second case, in order to discover which path is working, you will
need a message exchange, since probably there will be no packets back from
the receiving endpoint to the sending endpoint that allow the sending
endpoint to find out which is the combination of source and destination
address that it is actually working. So i guess that in this case, it would
make sense to have a protocol in the M6 layer to perform the available path
discovery.

Yes.

BGP is a non-starter as there can always be failures that don't show up
in BGP because of aggregation.

IMHO BGP is too slow, as we already agreed, but i am not uderstanding your
point about the aggregation.

I do understand it when you use bgp from the sending endpoint, so you cannot
see if the target endpoint is really reachable because aggregation hides it
from you.

Right, that was my point.

But if you use BGP plus rewriting as Erik suggests, then aggregation is not
a problem, because you use bgp as a mean to discover the available path, not
to see which address you should use.

Ah, I see: the host selects a destination address, then the router uses BGP to determine which ISP would be the best one to use to reach this address. Yes, this makes sense. However, there are two problems that are somewhat related to this:

1. the source address may be incompatible with the exit ISP
2. the destination address may be unreachable

The first can be fixed by rewriting. The second must be handled by the host. But if the host must handle selecting a destination address anyway, why not slightly extend this capability and let the host select a source/destination combo?

Assume hosts X and Y, X has ISPs A and B, Y has C and D and R means "rewriting allowed". Assume BGP prefers path X->A->C->Y and X->B->E->F->D->Y.

1 = routers with no special capabilities
2 = routers support source address based routing but not rewriting
3 = routers support source address based routing and also rewriting

              1   2   3
X(A)->Y(C):   +   +   +
X(A)->Y(D):   -   +   +
X(B)->Y(C):   -   +   +
X(B)->Y(D):   +   +   +
X(R)->Y(C):   -   -   +
X(R)->Y(D):   -   -   +

I think it's pretty clear that situation 1 is very sub-optimal but the added value of the rewriting feature is quationable. In situation 2 all the paths that are available in situation 3 are also available, it just may take a little longer to find the best one.

I was suggesting using a routing header to allow the host to force the exit
ISP i.e. as an alternative to the source address based routing

That wouldn't work, as "legacy" IPv6 hosts would have to insert such a header in order to function in a multihomed site.

Iljitsch