Preserving established communications (was RE: about draft-nordmark-multi6-noid-00)

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

Erik,

I will address the issues concerning the preservation of the established
session here and i will consider the issues related to ingress filtering is
a different thread.


> >
> > My point is that the usage of the routing system to determine which
locator
> > to use and to preserve established communication is not a good option
> > because:
>
> The routing system seems to be good enough for this purpose when sites are
> not multihomed.

Well, i am not sure about this.
Current studies of bgp convergence time are talking about up to 15 minutes
of BGP convergence when a route is withdrawn. Established communications
clearly don't survive this.
As i mentioned, bgp outage detection timer is recommended to be set to 90
secs, and as Iljistch mentioned, the default value in some commercial
routers is the double of that. Additionally, you have to add to this the
time required to reconverge, which can be even higher than that.
So, currently available intradomain routing does not always preserve
established seesions when an outage occurs. This is ok, since i guess that
this was not a requirement imposed to the desing of routing system (i mean
the preservation of the established sessions).

Now, this is a requirement to the multi-homing solution. Moreover, it is a
very difficult requirement. I mean, the goal of all this loc/id separation
is the preservation of established communications, since most of the
remaining requirements don't need this and could be addressed with
alternative (more conventional) mechanisms.
So, we are evaluating modifying all the hosts in the Internet to support
this feature, and it is ok.
The problem is that outage detection will be performed by bgp and it will
take 2 minutes. So we have build this loc/id split in all hosts but the
resulting solution is not useful to preserve established communications of
most apps (since i guess most apps need a better response time than this). I
don't know if it is worth it, what do you think?

>
> > - It is pretty expensive, since you need to inject the
> > reachability of all prefixes from the ISPs to the multi-homed site.
>
> Things are a bit less black and white than that. Depending on what
failures
> you  are concerned about you may not need anything but a default
> route from each ISP. For example,
>
>  - the link to the ISP failing - just a default handles that

Yes, also RFC3178 supports that and it is much simpler, since it doesn't
require the modification of all hosts to support it.

>  - the ISPs peerings with other ISPs fail and the ISP has no alternate
path;
>    maybe you assume that the ISP knows how to handle this.

How would the isp know how to handle this situation? i mean, the ISP has no
alternate path, so the only path is through the alternative isp of the
multi-homed site.
This is the relevenat case, imho, since is the case not covered by rfc3178.
So i would say that anyone implementing a solution other than rfc3178 would
want to be tolerant to this type of failure.


> If not you might need the ISP to give you the whole routing table.

Yes, this is it.

>  - internal failures in the ISP e.g. cutting off your PoP; perhaps just a
>    default route can handle this if the routers in the PoP base
advertising
>    the default on hearing IGP routes from other parts of the ISP's network
>  - the ISP having a broken setup where the BGP routes they offer to you
>    don't get withdrawn even if they've lost all upstream
> connectivity 3 days
> ago.
>    Oops - even receiving the full BGP table from then doesn't handle that
>    type of failure.

Right, but end-to end failure detection protect you from it

>
> > It is then my conclusion that path outage detection and locator
selection
> > has to be performed by the end-host themselves and not by the routing
> > system.
>
> This means that every host-pair that communicate (have an existing ULP
> connection/association - btw I don't know how to tell this for
associations
> implemented on top of UDP)

Well, an option would be to have a cache of host that the node is
communicating with, so that it can ping them periodically until the cache
expires. The cache lifetime is extended everytime a packet from/to that
destiantion flows.

>  have to exchange end-to-end hello packets every 10
> seconds or so. If you want to do VoIP you need to do them about every 100
> milliseconds. Imagine 100 Billion hosts or so communicating across the
Internet
> doing such e2e hello's. Couldn't that be another form of scaling problem?
>

:-)
Well, som additional cosndierations about this.
First, many existing ULP already exchange this type of messages, TCP ack for
instance, so hellos can be piggybacked into this messages. This would
require some tuning, though. Another way of considering this point is that
hosts already exchange millions of ack.
Second, the response time obtained is directly related to the cost. So, i
agree that preserving a VoIP requires exchanges every 100ms (even every 20
ms), but this is the cost of preserving this type of communication
uninterrupted. You could exchange hellos every 2 seconds, and the
communication would be preserved, but an interruption of a couple of seconds
will be perceived when an outage occurs. Nothe that the response time of
this solution is still a couple of orders of magnitude better than the bgp
based solution. Moreover, the exchange frequency can be negotiated by the
end-hosts, so that they can establish which performance and which cost they
are willing to accept.
Finally, the demands of such a solution is in terms of bandwidth, where i
guess that improvement is expected and scalability doesn't seems to be so
diffcult (as routing table growth, for instance)

Regards, marcelo

>   Erik
>
>