[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:
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
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
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
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
is the receiving end who detects the failure because it no longer
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
the receiving endpoint has to hint the M6 layer of the sending
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
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
detected the failure because of retransmissions, i guess. So, why
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
need a message exchange, since probably there will be no packets back
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
make sense to have a protocol in the M6 layer to perform the available
BGP is a non-starter as there can always be failures that don't show
in BGP because of aggregation.
IMHO BGP is too slow, as we already agreed, but i am not uderstanding
point about the aggregation.
I do understand it when you use bgp from the sending endpoint, so you
see if the target endpoint is really reachable because aggregation
Right, that was my point.
But if you use BGP plus rewriting as Erik suggests, then aggregation
a problem, because you use bgp as a mean to discover the available
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
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
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.