RE: survivability, rewriting

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

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

Agree.
My question is why don't just send a replicated data packet instead of
pings?
I mean, i have a hint that something is wrong, so if i have data packet
available, i send it replicated as many times as possible source dest
address combinations i have available.

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

I am supposing a communication that don't use acks, data streaming and the
like.

> If the ULP supports nacks then the receiving end
> can send those to get the message across sooner.
>

I am considering a communication that don't use nack neither, just one way
stream.

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

Ok

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

You don't have to convince me :-)


> 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 guess that X(A)-> Y(C) means that you are using as as source address the
address of X containing the prefix delegated from ISPA and as destination
address the address of Y with prefix delegated by ISPC, right?
and, what do you mean by + and -?

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

Well, if we restrict ourselves only to legacy IPv6 host compatible
mechanisms, i guess that the only options is some form of source address
based routing (whether in all the site or only in the exit routers), which
is fine by me :-)

More seriously, i think that this is a relevant point to evaluate different
approaches:
Different approaches to deal with ingress filtering can be compatible with
legacy internal hoats and legacy external hosts.
Source address rewriting is not compatible with none of them i.e. you need
modification in both ends to support it, so you need an additional mechanism
to deal with ingress filtering in those cases.
Source address based routing is compatible with both internal and external
legacy hosts
A routing header, as you note, is compatible with external legacy hosts but
not with internal legacy hosts

Regards, marcelo

> Iljitsch
>
>