[e2e] RE: mobility -> aggregation (TRAP?)

[J. Noel Chiappa]

    > From: "Dmitri Krioukov" <dima at krioukov.net>

    > In particular, the "fate-sharing" principle .. calls for *minimizing
    > the amount* of state in the network

Your timing is perfect... :-)

No, that's not what it calls for at all. As the quotation from the Clark paper
(which defines the "fate-sharing" principle) which I just included in that
update page says (emphasis mine):

  the intermediate packet switching nodes, or gateways, must not have any
  essential state information *about on-going connections*

It says nothing about state in the network which is related to the operation
of the network itself - nothing about how much or little you should have, or
anything else.


The Carpenter paper, on the other hand, does claim that the "volume of this
state must be minimized", but that's to some degree his personal opinion, and
one I somewhat disagree with (and in any case, what does "minimized" really
mean?)

It's also one that the Internet doesn't really even bother to pay lip service
to. Does anyone have any data on the amount of state (configuration data,
plus routing tables) in the average backbone router these days? I know for
sure it's many, many, megabytes.


    > (one of the major reasons being to minimize signaling, etc., after a
    > failure).

Now you're getting to the point I made at the end:

  a useful criticism of any design has to say something more than just "it
  has state in the core" .. It has to think about what that state buys you,
  about the cost and complexity of maintaining that state, about what happens
  when something goes wrong, etc, etc

This is not a simple analysis ("state in the core - yes/no?") - indeed, the
analysis of any of those proposed systems previously mentioned is pretty much
a PhD thesis - or in some cases, a whole research group's worth of them.


    > Please explain how keeping source- and/or connection-related
    > information in the state helps to achieve this goal.

First, you have to distinguish between i) what the Clark paper calls
"essential state information about on-going connections", and ii) other state
which might be related to ongoing traffic flows.

Nobody - and certainly none of the systems you named - *EVER* proposed
keeping that first kind of state in the network.

If you want to talk about other state related to ongoing traffic flows (e.g.
multicast routing entries), fine, an interesting and useful topic - but
remember, it's not a simple yes/no thing. (Just out of interest, speaking of
ongoing-flow state, what's your position on multicast?)


    > I don't think that any principle should be static and considered as the
    > absolute truth forever.

Sure. But some principles (such as the principle that a computer ought to
have a stack), while not mandated by mathematics, are such that mere mortals
ought to just treat them as Holy Writ.

	Noel