Re: Solving the right problems ...

["Randall R. Stewart (home)" <randall at stewart.chicago.il.us>]

Ok,

A very very late response to this thread... or at least part of
this thread, for some reason a while back I was knocked
off of the ietf list and thus only get things cc'd to the ipng list :-0
(and yes, I could re-subscribe but... I get so much email its hard enough
 keeping up... sigh..)

Now, I am going to comment on all of the bits of this thread
that I have been able to sort through (that went dually to ipng)...



Tony Hain wrote:

> In the ongoing saga about topology reality vs. application perception of
> stability, it occurs to me we are not working on the right problem. In short
> we have established a sacred invariant in the application / transport
> interface, and the demands on either side of that interface are the root of
> conflict.
>
> Mobile IP, and the multi6 DHT work are attempts to mitigate it through
> slight of hand at the IP layer, while SCTP attempts to mask the topology
> reality in the transport layer. (These are probably not the only examples,
> but they are the ones that come to mind this morning.) Yet none of these
> really do the job in all cases.

SCTP seems to me to do most of what you propose in this "layer"... assuming
an SCTP that includes the ADD-IP extension I can (and I have done this
with the KAME stack)

1) setup a SCTP association (connection in TCP terms) between two 
endpoints lets say
   10.1.2.1 port 2222 <----------------> 10.1.3.5 port 3333

2) on 10.1.3.5 move the cable to the 10.1.4.5 network

3) on the machine type "ifconfig fxp0 10.1.4.5 netmask 0xffffff00 ; 
route add default 10.1.4.4<cr>"

4) And the association stays up .. the application is un-aware that the 
topology under the machine
   changed.

Now of course if the application wants to be aware, it can "subscribe to 
events" that let it know
that it happened. This means it DOES hide the events letting the app 
keep a stable view of
the endpoint its talking to and YET at the same time allows some apps 
(ones that need or want
to know) find out. This seems to me to be EXACTLY what Tony is trying to 
get to... so why
would we re-do what we have already done?

We could do has Keith has proposed.. put it at a layer BELOW the 
transport. Now, what
do we end up with?

1) A NAT like thing that is playing games with the IP addresses and 
checksums (aka the psuedo-header)
<or>
2) Putting a psuedo IP address (the identifier) on the machine for the 
app to use apart and
   seperate from the real physical IP address in use.

3) ??others that I can't think of??

If we choose <1> it seems ugly to me.. I don't like NATs and now we just
put one IN your host... what else will break?

If we choose <2> and arguably you can do this without a new layer.. 
There are several
papers on how and I know I did such a thing long ago at NYNEX for their 
voice-dialing
system... you end up with some other problems that are also in <1>... 
which all boil down
to the fact that the transport has knowledge of failures your upper or 
lower layer will
NOT have (hey I just retransmitted to IP-A .. need its the Nth time
I have done so). This is key to detection that there is a 
problem....this information will
just not be present in either approach.

Now long ago, Qiaobing Xie and I started down this path of trying to get 
fault tolerant
applications. SCTP was a direct result of that.. we put the path 
redundancy in the
transport where you could use the information it holds to better make 
fail-over choices on
paths. But there is another aspect to this as well.. the other half of 
the equation if
you will... that is I have

APP-1   <-------------------------------------> Peer-Of-App-1

Note I say Peer.. it may be a server .. it may NOT and you might be 
doing some
peer-2-peer networking...

Lets say that Peer-Of-App-1 is redundant and I can talk to any of the 
peers. And
more so each side of this (APP-1 and the peers) are multi-homed. We 
(Qiaobing
and I) divided this problem in to two pieces..

1) The path level multi-homed redundancy portion... i.e. what became 
SCTP.. lets keep the
    transport up as long as there is connectivity between the two no 
matter which
   IP addresses come/go/up/down what have you.

2) The app not caring WHICH Peer its talking to.. as long as it gets 
done what
   it needs to. This other redundancy we put in what is NOW the RSERPOOL
   working group. The app gets an identifier for Peer-Of-App-1.. and if 
there
   is a failure it can silently move to an alternate peer.. and of 
course we envisioned
   the connection between the two being SCTP.. so all that path-level 
redundancy was
   handled at transport...

I just don't see the need for this to tell the honest truth..

A) We have SCTP which Tony has not indicated (at least as far as I can 
see in this
     thread) how his new layer does anything different then what is 
already there.

B) We have an ongoing effort in rserpool to finish out the upper level 
redundancy (were almost
     done I think.. or close :>)

So why do we need to re-invent a solution???

This seems to me like the introduction of yet another NAT like 
mechanism... this is percisely
why IPv6 is where its at today... call your local ISP, ask them about 
IPv6... what will they answer you?

I have two ISP's and have talked to MANY people in both.. and you get either

a) huh?
<or... less often>
b) Oh, yeah, I did hear something about that.. but hey its just 
something I need
   to read about someday in the future... (future being around the time 
I retire).


Adding this layer just makes NO sense to me...

R


> We all agree that applications should not be aware of topology. At the same
> time,  application developers insist on the right to pass around incomplete
> topology information. There are arguments that the IP address is overloaded
> as an endpoint name. I don't particularly buy that, because the real
> endpoint is either a protocol, or a specific port of a protocol. From one
> perspective, when applications use addresses in referrals, they are
> specifying that routing through a particular point in the topology will
> reach the desired endpoint named 'transport/port-id'. But that is a
> semantics and perception discussion which doesn't help reach the goal.
>
> In any case, what applications need is a stable reference to other
> participants in the app. Yet we know that current and projected reality says
> that topology is not stable, or consistently reachable. This could be due to
> technology issues of the underlying links, or simple policy. Either way, the
> network as seen by the transport layer is not, and will never be stable or
> consistently reachable from everywhere. Given that, the direct interface
> with the transport layer creates a failure mode for an application expecting
> stability. 
>
> Where this leads us is to the sacred invariant, and the need to solve the
> problem in the right place. I suggest it is time for the IETF to realize
> that the protocols are no longer being used in the network of 1985, so it is
> time to insert a formal stabilization layer between application & transport.
>
>
> Such a layer would be responsible for managing intermittent connectivity
> states and varying attachment points of the transport layers below.
> Applications that interact with this layer would be insulated from the
> inconsistencies being experienced by the transport layer. It would also be
> reasonable for this layer to manage multiple simultaneous transport
> interactions so that the application perceived a single data path to its
> peer. With appropriate trust between the stack and the network policy, this
> would even simplify the process of QoS markings for parallel related data
> sets. 
>
> The next place that leads us is to a name space. At this point I see no
> reason to avoid using the FQDN structure, but acknowledge that the DNS as
> currently deployed is not even close to being up to the task. The protocols
> are not so much the issue as the deployment and operation model that is
> focused on a limited number of nodes operated by a small community of
> guru's, where the expectation is that any changes occur on the order of
> several days or longer. What we ultimately need in a name service to support
> the suggested layer is the capability for every consumer device with
> electrons in it to automatically and dynamically register its current
> attachment information with rapid (that doesn't mean sub-second, more along
> the lines of a cell phone that powers up away from its home) global
> convergence. As there are multiple trust boundary issues involved (because
> not every device will be subscribed to a service), making this scale will
> require pushing the database distribution out to smaller pockets. Making it
> reliable for Joe-sixpack will probably require that part of the
> infrastructure exists on his side of the interconnect & trust boundary from
> any other networks. Automating the attachment of a massive number of small
> dataset servers will probably require something with better scaling
> characteristics than the current DNSsec deployment model.
>
> Since many networks have usage policies established around the sacred
> invariant, there will need to be some recommendations on how to apply those
> policies to this new layer. We could even consider a protocol between this
> layer and a policy entity that would aggregate applications into a policy
> consistent with the what the network can deliver for various transport
> protocols. This distribution of policy awareness would have much better
> scaling characteristics than per app signaling, as well as the ability to
> locally group unrelated transports that any given app might be using.
>
> Bottom line is that we are spending lots of time and effort trying to force
> fit solutions into spaces where they don't work well and end up creating
> other problems. We are doing this simply to maintain the perception of
> stability up to the application, over a sacred interface to a very unstable
> network. Stability to the application is required, but forcing applications
> to have direct interaction with the transport layer is not. Yes we should
> continue to allow that direct interaction, but we should be clear that there
> are no guarantees of stability on that interface. If the application does
> not want to take care of connections coming and going to the same device at
> potentially different places, it needs to have an intermediate stabilization
> layer available.
>
> Tony
>
>
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to majordomo at sunroof.eng.sun.com
> --------------------------------------------------------------------
>
>
>  


--
Randall R. Stewart
randall at stewart.chicago.il.us 815-342-5222 (cell phone)