> With SPF each node computes its individual tree towards all
> the other nodes. The sum of all these (n) trees
> will most likely cover the entire network. Some may see this
> advantageous (traffic is distributed all over the network).
> However by "DiffRout" as I like to advocat some traffic can
> be locked into ONE particular slim tree of links (e.g. the
> smallest size tree), and having several such slim trees (=
> road systems), which are constructed in awareness of
> each other, and which may even have assigned bandwidth, much
> better control of the traffic/network can be executed.
Ok. Understood. Let us discuss without taking problem space
and applicability statement factors ( as you dont have one.)
1. The diffserv architecture does not assume anything about
routing stability. I am not sure, but the original designers
should have assumed that *routing system should be stable for
a predictable functioning of diffserv components*. So, in a
*EXTREMELY* congested network, all queuing and scheduling
mechanisms may show some anomalous behaviour ( I am not sure
again.)
How will diffrout help in such a situation. I dont think
you can do some sort of routing based on DSCP at that point.
2. DSCP is actually for classification (queueing mechanism.)
Can you just explain the gap between *DSCP as used for
classification* and *DSCP as used for routing*? Remember,
you are using DSCP both for data plane and control plane
work here.
I am also sceptical of the following issues:
- scalability: Since you are maintaining multiple Routing
tables, doing at line rate is pretty difficult and hence
doesnt scale well.
- complexity: This work increases the complexity at per
router level. Some people complain of increase in complexity
for just adding three more lines in the original forwaring algo
(to include RED features.) I dont know how much complex
the router becomes because of diffrout.
- end to end: Diffserv is defined only for edge to edge. How will
diffrout behave when considering end to end is still open.
> The algorithm I showed last week is very fast and doesn't
> constitute any performance problem.
How are you justifying that it doesn't consitute any performance
problems. Do you have any mathematically tractable model or
simulation work?
Let me suggest you a method for going about your analysis:
1. Formulate diffrout as a *diffserv routing problem* with
all possible constraints. prove them to be NP-hard and if possible
find some heuristic results ( genetic algo based or local search
one).
Refer *http://www.research.att.com/~jrex/papers/ieeecomm02.long.pdf*
2. Define QoS compuatation algebra for your work.
Refer *http://citeseer.nj.nec.com/sobrinho01algebra.html*
3. If heuritic method is not feasible, go for some approximation
methods and prove using some theoretical results. Then support your
performance claims with some simulation results.
If you do all this, I will accept that your algorithm doesn't
consititute any performance problem.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:04 EDT