RE: survivability, rewriting

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

> We may want to do some extra checking before immediately failing over.
> For real time stuff, transport protocols are usually implemented inside
> applications. This means the mh layer may receive far too many hints
> from the transport layer to actually act on each one of them.

Good point.
I guess that the M6 layer will have to react to a hint and then ignore the
next hints for a certain period

> 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
(see below)
>
> I'm thinking along the lines of sending out packets with all possible
> source/dest locator combinations and then see what comes back and how
> fast. Obviously we don't want to set off such a "ping bomb" too often.
> And we very likely don't want to use actual ICMP echos for this, but
> what do we want to use?
>
[...]

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

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

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?

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.

[...]

> > I mean, we are going to have two mechanisms, one based on bgp +
> > rewriting
> > and the other one is based on ULP hints.
>
> 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.
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. The information about what address to
use is carried in the source address field of the received packet.
Anyway, could you put an example where tha aggregation cause the problems
that you mention? (sorry to ask you this, but i really fail to see the
problem here)

[...]

> >> But "legacy" IPv6 also doesn't permit
> >> rewriting, so we must be prepared to handle this. The obvious solution
> >> is source address based routing, but it doesn't seem like everyone is
> >> convinced.
>
> > Well, we could use a routing header.
>
> You mean a routing header indicates permission to rewrite?

No. sorry for not being more explicit.
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 seems
> rather extreme. I'd use a different link layer encapsulation (=
> ethertype) or even IP version number first.
>
> > Even we could define a routing headers
> > that is elimated by the exit routers, in order to addresss the MTU
> > reduction
> > problem.
>
> That would only work if the first hop has a higher MTU than the rest of
> the path... Also removing some data in the middle of a packet is an
> extremely expensive operation in software.
>

Yes, but isn't this the most usual case?

> > An obvious comment about source address based routing is that source
> > address
> > based routing only has to be implemented within the multihomed site.
>
> Yes. It is not unthinkable that a host or even a small site has
> connections to two or more ISPs and/or larger sites. For instance, a
> laptop may be connected to the multihomed enterprise network while at
> the same time connecting to a GPRS ISP, or a home user could have an
> ISP connection and a VPN back to the multihomed enterprise network. But
> I think source address based routing or rewriting doesn't have to be
> arbitrarily stackable without the layers knowing about eachother.
>

I think that i agree with you. I think that we need a mechanism to allow the
host to indicate if it allows rewriting in the packets, is this what you
mean?

Regard, marcelo