Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 - CLARIFICATION

From: "Alan O'Neill" <[email-masked]>
Date: Thu, 16 May 2002 03:11:57 -0400

I think this is maybe a bit of a red herring wg for the following reasons.

MIP is a soft-state refresh protocol with periodic refresh as a fraction of
the binding lifetime. 

Any arguments about statefulness come down to the refresh interval you are
prepared to tolerate in return for higher availability through reduced
unavailability when a node crashes. When a router goes down we are typically
happy to wait for OSPF convergence times which are large numbers of seconds.
We shouldn't ask for much more from MIP. Adding a GFA or an RMA (from
Nested) doesn't change the flexibility of the operator and/or MN to tune
lifetimes, and having a big router or a big regional element fail impacts
just as many flows for OSPF convergence time so I feel that is also a bit of
a red herring. especially in a tree network..

The bigger but different problem here is that costly and localised high
availability solutions (hot-standby) that vendors would try to use to
protect the regional element whilst also having long lifetimes to reduce the
signalling overhead, do not work with GFA because the HA must also be
updated. This is why the RMA places a routable MN specific address in the HA
so that these hot-standby techniques can still be localised. This is the
aspect of GFA that is problematic here...

Alan.

-----Original Message-----
From: Phil Roberts [mailto:[email-masked]]
Sent: 15 May 2002 05:55
To: [email-masked]'
Subject: [mobile-ip] Regional Registration Last Call Resolution Issue #4

Several folks raised the issue of to what extent introducing regional
registration entities in the visited network violates principles of the
Internet architecture, specifically with regard to the introduction of
single points of failure in the communication path of visiting nodes.

I've excerpted the relevant text from rfc 1958 on the architectural
principle which is at issue.

   "The end-to-end argument is discussed in depth in [Saltzer].  The
    basic argument is that, as a first principle, certain required end-
   to-end functions can only be performed correctly by the end-systems
   themselves. A specific case is that any network, however carefully
   designed, will be subject to failures of transmission at some
   statistically determined rate. The best way to cope with this is to
   accept it, and give responsibility for the integrity of communication
   to the end systems. Another specific case is end-to-end security.

   To quote from [Saltzer], "The function in question can completely and
   correctly be implemented only with the knowledge and help of the
   application standing at the endpoints of the communication system.
   Therefore, providing that questioned function as a feature of the
   communication system itself is not possible. (Sometimes an incomplete
   version of the function provided by the communication system may be
   useful as a performance enhancement.")

   This principle has important consequences if we require applications
   to survive partial network failures. An end-to-end protocol design
   should not rely on the maintenance of state (i.e. information about
   the state of the end-to-end communication) inside the network. Such
   state should be maintained only in the endpoints, in such a way that
   the state can only be destroyed when the endpoint itself breaks
   (known as fate-sharing). An immediate consequence of this is that
   datagrams are better than classical virtual circuits.  The network's
   job is to transmit datagrams as efficiently and flexibly as possible."

draft-iab-arch-changes-00.txt provides a discussion of this issue of
fate-sharing in middleboxes and asserts that the principle is preserved in
the case that the middlebox is a partner in the communication when the
failure can be detected and dealt with.:

   "The idea of fate-sharing survives this recursion, but requires that
   all application state created in middleboxes must be capable of re-
   creation after failure. Additionally, to support this requirement,
   where a function cannot be fulfilled completely, reliably and
   securely by two endpoints of a conversation, the necessary
   middleboxes to fulfil the function should be explicit partners in
   explicit communication with at least one endpoint (or, by recursion
   of the same principle, with an intermediate middlebox). In other
   words, middleboxes should not be invisible, because their failures
   need to be detected and dealt with by their communication partners."

As currently specified it's not immediately obvious how the regional
registration agents are compatible with the above guidelines.  It's
conceivable that they can be made so, and perhaps it's immediately obvious
to others how they are so.

This issue is not insurmountable but the functionality does need to be
specified in a way that preserves the fate sharing principle and allows for
one party in the communication to detect and deal with a failure of one of
the new registration entities.

---

From: "Alan O'Neill" <[email-masked]>
Date: Mon, 20 May 2002 06:28:14 -0400

Fate-sharing is certainly another useful but equally dark cave to explore on
this thread ..

-----Original Message-----
From: James Kempf [mailto:[email-masked]]
Sent: 20 May 2002 13:44
To: Alan O'Neill; Phil Roberts; [email-masked]
Subject: Re: [mobile-ip] RR Last Call Resolution Issue #4 -
CLARIFICATION

Alan,

The issue isn't end to end, it's fate sharing. In some circles, end to
end has become so theological that it is the only Internet architectural
principle people cite. It is unclear how a routing proxy and the host
could communicate to effect fate sharing.

            jak

----- Original Message -----
From: "Alan O'Neill" <[email-masked]>
To: "Phil Roberts" <[email-masked]>;
<[email-masked]>
Sent: Friday, May 17, 2002 5:09 AM
Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 -
CLARIFICATION

> I thought it might be useful if I stated specifically why I feel MIP
doesn't
> affect end to end at all.
>
> By definition it is a tunnel protocol coupled with Internet routing
which in
> addition has host routing into that tunnel. The packet within the
tunnel is
> not touched or modified on its travels and hence end to end is not
affected.
> The IP address is still the identifier and the locator, but routing
has
> simply moved the location. The redirection is at the edge of the
network
> (subnet to subnet) so preserving end to end. The fact that the HA is
on an
> edge in the core (just like a webserver) doesn't change the argument.
>
> The HA has one tunnel endpoint and the FA or MN the other. If we put a
GFA
> in the middle then it is only affecting the tunnel not the inner
packet. Now
> we wouldn't claim running multicast over unicast tunnels breaks end to
end
> and we wouldn't claim that MPLS lable switching (another switching
layer
> carrying user packets) breaks end to end either. End to end is about
the
> users packets and ensuring that the endpoint is aware of stuff going
on. The
> MN is issuing the redirection so I think we are completely clean here.
>
> The issue with GFA and MIP is simply to me the soft-state requirement
and
> its impact on availability, unavailability and signalling load. We
begin to
> impact end to end when the soft-state refresh rate in insufficient to
> protect the users interests in the flow...
>
> Hope that is clear and logical,  Alan
>
>
> From: Alan O'Neill [mailto:[email-masked]]
> Sent: 16 May 2002 16:42
> To: Phil Roberts; [email-masked]'
> Subject: RE: [mobile-ip] RR Last Call Resolution Issue #4 -
> CLARIFICATION
>
>