[e2e] EC++N

[Jon Crowcroft]

 >>If you look at the flows at some Inter-AS point and they vary in an 
 >>unstable way, you don't have enough information to say that that is a 
 >>problem.   The problems are ones of system behavior, not local behavior.
 
 >>There is a lot of evidence that flows driven by applications in general 
 >>fluctuate on all time scales.  In fact, except when you saturate network 
 >>capacity, computer-computer applications are designed to do exactly that.


the tension in this is the engineering tradeoff between
protection and utiilisation &
resilience and responsiveness

subject to the constraint of hw predictable the traffic matrix is.

the usual assumption is that 3^3 models (traffic is usually
shortlived, usually local, and mostly the destinations change between
places near each other too).

in th global net, these appear to be false assumptions (=yes within
the US< which is where most measuremnets and network provisioning has
happend they look ok, but intercontinental traffic doesnt appear
anecdtoally to look so regular)...

my personal take is that I would like to have a system that had
properties that looked like fuzilly pinned path-segments in parts of the net
(fuzzy, because i'd like to take advantage of load balancing, fast
local failover and so on, but all using the same signaling/addressing and
routing architecture as i use for everything), and compeltely under
specified path-segments for other parts  - i.e. what i'd like is NOT
MPLS (i.e. not local labels) and not full or oose source routing, but
something like an AS Level source route....

so what i'd do is take Paul Francis FTIF/PIP architecture, and re-use
it - i'd need a system (the ECN++ idea was part of this) for reporting
to the routing system what conditions on path-segments are like (not
BGP:), and a system for end users to discover this, and to specify
(liek a source route, but not at the "list of IP  addresses" level, at
the level of granularity of "traffic engineererd region ids) - given
IPv6, for exampel (only for example) i have TWO 128 bit fields - if we
too ksomething like the GSE idea, I would have an 64bit EID for each
end which is immutable, and 8 16 bit ids to play with - the average AS
path length is 7, so this sounds pretty good....

the new routing layer  (if we must call it that) distributed
information about the inter-as points, and the user signaling is now
per packet, and is in the "address" they use - multihomgng, multicast,
mobility are all quite simple i nthis system......it looks like
labels, but they are not often swapped (but can be ) - given the right
economic interface (payment and charging) we have another dimension
for incentives which makes sure that the providers and subscribers
dont cheat on each other (theft and denial of service)...but we retain
topologcial information hiding nicely.....and 2^16 is more than most
people envisage for a single lambda domain for a while yet too....

one of the goals here is to allow massively quick responsiveness, but
_usually_  to "go with the flow" - so these 16 bit ftifs are
multiplex/aggregate ids (like virtual circuits if yo ulike ,but only
for path segments...)and the aggregates are across cores (so core
stateless fq type systems can operate within those, using pure ip
addresses internally for forwarding...or usign an FTIF to MBPLS LDP if
they want)...

another goal is to avoid explicit signaling (i.e. decouple
user-network request and network-network and network->user
notificaiton of net circumstances, and to make admission control
purely implicit)..and to therefore keep the RTT down to as close to
zero as possible for the user to get as good an approximation to any
service level they can afford as quicky as possible - of course, the
confidence goes up as the user (or their nearest dearest
proxy/broker/congestion manager) waits to accumulate more data about
alternate path conditions....and tarrifs...

all this probably works given small world stuff....but  maybe not....

ramble on...

j.