Subject: AW: Differentiated Routing, not only plain rambo-SPF

From: Hummel Heinrich <[email-masked]>
Date: Fri, 2 Aug 2002 13:52:48 +0200

Hi Jing,
Find my comments inserted.
Regards
Heinrich 

1) if we want to route with DSCP it should be desired that  logical views of network based on each possible
DSCP is computed ?
HH=>
Yes, this is feasable. IMO, the alternative, that each link advertises all the DSCPs i.e. all the road systems  
it wants to be a part of, is not good eenough for two reasons:
            1) Only by computation we can make sure that each road system is "routable", i.e. enables road system
               internal transport between a particular set of edge routers.
            2) Some road systems are just the overflow-/2nd-best-route, 3rd-best-route road systems w.r.t. another
               road system. This cannot be assured without computation.     

2.)  Each router builds up a seperate routing table for each possible DSCP , and there exist a default routing table
       for packets whose DSCP are not set  ?
HH=>
     Differentiated road systems only make sense, when each of them uses only a part of the network links. A smallest
     size tree between a confined set of edge routers would yield such a "slim" road system. 
     If all your nodes are leaf nodes, then there is no difference between a shortest path tree and a smallest size tree.
     But on the other side, it still must be possible to send a packet from any edge or core router to any edge or core 
     router. I.e. we still need the exisiting best-effort road system. As long as you have only one road system you
     won't have to mark it. But as soon as there is a second one, you have to mark not only the second one 
     but also the first one. Will say you need one DSCP for traffic which shall be forwarded according to the current
     routing tables.

3.)   When a new packet arrives, the dispatching logic may look like :

      Procedure  DSCP_BASED_DISPATCH ( incoming_packet )
            if   DSCP   then
                 if  (  DSCP-related-table-exist )
                     running-table =  DSCP-related-table;

           if  running-table==NULL
                  running-table = default-table;

           out_port= find_routing_item( incoming_packet);
           enqueue(out_port, incoming_packet);

        END PROCEDURE
HH=>
Yes. I see, you already addresses the case where a packet is forwarded NOT as it should, i.e. not within the respective
road system. Of course, this needs to be covered, too. And yes, as you describe, by using the default (best effort) road system.

But, How could the logical view be computed?  DSCP is just for queueing mechanism, should that be included in LSA?

HH=> Life would be easier, if we had more available bits (we still have 2 CU currently unused Bits). But we don't have
64 Service Level Agreements either. It should be possible to satisfy DiffServ as well as DiffRout :-)

And, I think there may other problem as extensiblility and stability.
HH=> Sure. But compare it with DiffServ. DiffServ wasn't done either by one single draft and by one single IETF meeting session.

And,the last , I'm not so clear about the method computing shortest size tree, and I'm very interested in your work of
minimal partial mesh between n sites of a VPN. Would you please give a little more word or some reference sites ?

HH=>   

The idea was to interconnect n sites (PEs or CEs) by a minimal partial mesh of tunnels.It could only be a tree of
n-1 tunnels. And well, a tree of those "shortest" tunnels, which nevertheless interconnect all n sites. In principle,
it is a selection process as to sort out n-1 tunnels from n(n-1)/2 candidate tunnels.Thereafter, add those n-1 
tunnels which are inverse to the selected n-1  tunnels.

Preparation: Compute n Dijkstra-trees whereby each time another site-node becomes the root.As a result you have the best route from any node to any node (edge node as well as core node). You may sort all of these n(n-1) routes according to their
weight sums in ascending order.And you may associate a REGARD/DISREGARD-Bit to each of these routes (for speeding up the algorithm). Initially set all these Bits to REGARD=1.

Iteration:
As I told already, start out with n (separated) partitions, whereby initially each partition 
just contains  one site-node (no links yet). Also the initial set of tunnels, which finally shall become the
VPN PARTIAL MESH,is empty.
Make n-1 iteration steps.

At each iteration step, determine those two partitions, which can be combined by the shortest route(=tunnel)
among all those routes which are marked REGARD.
 
Combine the two partitions (logically), but in reality do this:
Add this determined shortest route/tunnel to VPN PARTIAL MESH. Set the REGARD/DISREGARD-Bit to DISREGARD=0 for all
those routes, which are "internal" to this combined partition. Note: this includes this shortest route/tunnel.
Precisely set the bit to DISREGARD for all those routes, wherebe the route started at a node from the one partition
and ended at a node from the other partition.

Do this n-1 times.

So far this was all about forming a "minimal size tunnel tree".

Only slightly different would be the algorithm for building what  I used to call a "minimal size multicast tree",
which extends between the sender node and the receiver nodes.

Preparation: 
Compute Dijkstra-trees as many as you have nodes in your network (edge as well as core nodes).
(So you also know the shortest route between any two core nodes as well).Hereby, each time another
node is the root node.

Like above, sort all these routes according to the ascending order of their weight sums, assign a REGARD/DISREGARD-Bit
to each of them, and initialize all these bits to REGARD=1.  

Iteration:
Start with an empty set of routes, called MULTICAST TREE, and with N partitions whereby each partition would only contain one
sender resp. receiver node initially (  for building a road system it would be any edge router 
with attached LAN, Host, ext.interface).

At each iteration step, determine those two partitions, which can be combined by the shortest route between any
node in one partition and any node in another partition. Hereby consider only those routes which are still marked REGARD.
 
Combine the two partitions (logically), but in reality do this:
Add this determined shortest route to MULTICAST TREE. Set the REGARD/DISREGARD-Bit to DISREGARD=0 for all
those routes, which are "internal" to this combined partition. Note: this includes the determined shortest route.
Precisely, set the bit to DISREGARD for all those routes, wherebe the route started at a node from the one partition
and ended at a node from the other partition.

Do this n-1 times.

As a result MULTICAST TREE will contain a list of routes (which are lists of links/nodes).
Or you may look at it in this way: MULTICAST TREE contains a list of links/nodes (which, by chance form a tree graph with
no special (root) node at all).

Take this list of links/nodes as your "basis network topology". And which ever node is part of it may run the most primitive
Dijkstra, i.e. whereby each link-weight is equal to 1, as to compute a tree which spans this tree-topology :-).
By doing so, that node will find out the right adjacent next-hop link with respect to each 
LAN/Host/ext.interface reachability prefix, i.e. can build a respective routing table.

Let's rename MULTICAST TREE to ROAD SYSTEM-for-DSCP "xyz".

It is very important that each node which is part of ROAD SYSTEM-for-DSCP "xyz", has computed the identical set of
links. This means, when, during the iteration, a particular shortest route between some separate partitions is computed,
it must be done in an unambiguous way -  yes, even if there were several equally shortest routes.Tie breaker rules
will be needed.

> Let's be concentrated again. And let me get to the heart of the matter.
>
> Obviously I am not the only one who thought about using the DSCP also for doing Differentiated Routing.
> Will say: not the only one who thought about indexing different Routing Tables by different DSCPs.
>
> IMO, these routing tables should represent different and very distinct and differentiated road systems.
> This is only possible, if they are genuine partial structures of the total network. In addition to them we still need
> that "default"-road system which is identical to the entire network (e.g. in order to ping any node), i.e. today's routing tables.
>

[snip]

--
Jing Shen

State Key Lab of CAD&CG
ZheJiang University(YuQuan)
HangZhou, Z.J. 310027
P.R.China

Tel: +86-571-87932423

Email: [email-masked]

**********************************************************************
* The SunShine of life is made up of very little beams which is      *
*  bright all the time                                               *
**********************************************************************

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 2 Aug 2002 13:52:48 +0200

Hi Jing,

           if  running-table==NULL

        END PROCEDURE
HH=>

HH=>   

Iteration:

Do this n-1 times.

Preparation: 

Iteration:

Do this n-1 times.

[snip]

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 2 Aug 2002 14:37:08 +0200

Let me resend this email and correct a stupid tiny error w.r.t. the "smallest size tunnel tree" algorithm.
However, the error highlights an important aspect: For building this tunnel tree, you have to combine two partitions
by means of an entire tunnel between some two VPN-sites which are tunnel endpoints.
No split in the middle of a tunnel will occur.
Where as:
For building a "smallest size tree" - road system
you have to combine two partitions by means of ANY route between these partitions. 
Eventually, one or two completely new branch nodes may be generated at this, at that, or at both partitions.

I will mark the change with  CHANGE***CHANGE and END OF CHANGE*** END OF CHANGE in the text.

Heinrich

-----Ursprüngliche Nachricht-----
Von: Hummel Heinrich [mailto:[email-masked]]
Gesendet: Freitag, 2. August 2002 13:53
An: [email-masked]'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: AW: Differentiated Routing, not only plain rambo-SPF

Hi Jing,

           if  running-table==NULL

        END PROCEDURE
HH=>

HH=>   

Preparation: Compute n Dijkstra-trees whereby each time another site-node becomes the root.As a result you have the best route from any
 
CHANGE***CHANGE

site node to any site node. Here we can ignore those routes which do not start or end at a site node.

END OF CHANGE *** END OF CHANGE

You may sort all of these n(n-1) routes according to their
weight sums in ascending order.And you may associate a REGARD/DISREGARD-Bit to each of these routes (for speeding up the algorithm). Initially set all these Bits to REGARD=1.

Iteration:

Do this n-1 times.

Preparation: 

Iteration:

Do this n-1 times.

[snip]

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Fri, 2 Aug 2002 14:37:08 +0200

Heinrich

-----Ursprüngliche Nachricht-----
Von: Hummel Heinrich [mailto:[email-masked]]
Gesendet: Freitag, 2. August 2002 13:53
An: [email-masked]'
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Betreff: AW: Differentiated Routing, not only plain rambo-SPF

Hi Jing,

           if  running-table==NULL

        END PROCEDURE
HH=>

HH=>   

 
CHANGE***CHANGE

Iteration:

Do this n-1 times.

Preparation: 

Iteration:

Do this n-1 times.

[snip]

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 05:02:37 -0500

-- Hummel Heinrich <[email-masked]> 
wrote: > From  [MPLS-OPS]: MPLS Debacle back to
> [routing-discussion]:Differentiated Routing, not
> only plain rambo-SPF
>  
> 
> Senthil,
> This email of yours as well as your previous one
> only confirms my statement, that
> the entire Internet community  (or at least you and
> some others) is the prisoner of this rambo-SPF
> routing algorithm.
> All the protocols you have enlisted (...,BW
> inversion SP,...PNNI,..) and let me also add
> the reverse SPF in some multicast models, share this
> egocentric  SPF view.

> I am    N O T     talking just another brand of
> rambo-SPF.

My .02$:

1. The diffserv architecture, as of now, defines only 
the data plane work.  control plane activities( routing,
signaling etc)  are still open questions. 
 My argument is contradictory to what you suggest:
An effective load balancing in diffserv can be done 
by taking SPF algo into consideration. The NP-hardness 
in the existing *routing problem* formulations can be 
be approximated to polynomial time effectively by taking
both diffserv and SPF into consideration(as paths are 
predictable in a diffserv domain. )
 Most of the current routing problems formulations 
are solved by means of heuristic methods. But one can 
approximate to polynomial time by taking both SPF and 
diffserv into consideration.

Note: I am just tossing an idea. I will update you 
all once i get some good results.

2.[ some diffrout def from the discussion]

*Certainly, the basic idea of DiffRout is to use 
the DSCP-Bits, or even all 8 TOS-bits, for addressing 
different Routing Tables for looking up the next hop 
link (you can as well have one common Routing Table 
but search for the right entry while using destination 
address AND DSCP as search keys - this is up to the 
programmer).*

*In normal, state-less IP routing we cannot do 
QoS-Routing, nor sneak-around the congestion-area 
routing, nor traffic balanced routing. Instead, all 
of this is left to MPLS, where multiple states and 
multiple LSPs and multiple signalling is required.
With other words:I try to enable QoS-Routing, 
"sneak-around the congestion-area" -Routing, 
traffic balanced -Routing.*

*the intersection of all the subsets (ie., 
(QoS using MPLS-(DiffServ-Aware-TE) will make 
a *real-good* impact on end-to-end performance 
in the global Internet*   

Do me a favor. Replace the term  *DSCP* with 
*CoS* and *Diffserv* with *MPLS * in the above 
definition, you can call your new routing
scheme as *multi-protocol routing*. 
( humorous aside: Tips from a networking insider 
http://www.cs.ucsd.edu/~savage/papers/OO01.pdf :-) )

Thus said, coming with a new scheme is not a big task,
problem space and applicability statement is very 
important.

Read *An Overview of the New Routing Algorithm for 
the ARPANET, J. M. McQuillan, I. Richter, E. C. Rosen 
(Proc. Sixth Data Comm.Symposium, November 1979)*
http://www.acm.org/sigcomm/ccr/archive/1995/jan95/ccr-9501-mcquilln.pdf 

The above work marked the begining of transition from 
the old ARPANET distributed routing algorithms to 
SPF. The authors start with the *problems with the 
original algorithm*, then *need for SPF* and convinces 
the network floks that *SPF is just an increment to 
the original algorithm*. 

I am not asking you to formulate diffrout as an increment 
to SPF but just enlighten us *problem* and *need* of 
diffrout.

- Senthil.

> 
> Also, it wouldn't be helpful to follow your advice
> (come up with requirements, application
> statements,...)
> because if I did you would read all of it with your
> SPF-centric view in mind. You even do so now, after
> I have explained how each router may aquire the
> identical view of some road system.
> 
> Another analogy: 
> When you fly to some meeting place, you may get a
> flyer-map at the hotel concierge. The flyer-maps may
> be the same
> no matter at which hotel you stay. But, eventually,
> they have a different "You are Here" markation
> depending on
> the specific hotel. I am looking at the propagated
> road systems by a commonly shared view first, then I
> respect the
> different "you are here" markation. Rambo-SPF
> however means:"I am here.I see the world only from
> my point of view."
> Taking into consideration any kind of constraints
> and whichever weights doesn't change anything of
> this egocentric
> view + behavior with all its disadvantages.
> 
> 
> Heinrich
> 
> Von: senthil ayyasamy [mailto:[email-masked]]
> Gesendet: Samstag, 3. August 2002 09:40
> An: venumadhav josyula; Hummel Heinrich;
> [email-masked]';
> [email-masked]
> Cc: Andrew Walding; [email-masked];
> [email-masked]
> Betreff: Re: AW: [MPLS-OPS]: MPLS Debacle
> 
> 
> 
> > See how many
> > QoS
> > > routing schemes were proposed, researched and
> not
> > > deployed. See what is the problem with those
> > routing
> > > Variants and then suggest differential routing
> > > Scheme.
> > >
> > Ok tell me why would not such a scheme work?
> Where I mentioned  *differential routing* wont
> work. Proposing new ideas are always easy. Let me 
> illustrate with an example.
> 
> SPF+ variants of SP algo (widest SP, shortest widest
> bandwidth path, bw inversion SP, ...)+ optimal
> multipath+source routing+ loose source routing+
> explicit paths (MPLS)+ k-shortest path and its
> variants+QoS routing( load sensitive,delay
> sensitive,
> single metric based,multi-metric based) +OSPF
> extensions+ all dynamic routing schemes as mentioned
> 
> in Ash book+PNNI + all frame relay and other type of
> routing+ MPLS based (constrianed or whatever)+
> overlay
> based routing+ onion routing+hot potato+ cold potato
> routing+...
> 
> I have listed a *few* unicast routing schemes. I can
> list more routing Schemes taking multicast, any cast
> into picture... leave alone ad-hoc, host mobility,
> network mobility, topology independent ...so on..
> 
> Most of the above routing schemes are subsets of
> some
> of the listed schemes. So suggesting a new routing
> scheme is not a big work. Using a simple combination
> and taking  some new technologies into picture, one
> can come up with a new routing scheme. But frankly
> that's not a correct approach for any protocol
> developed in IETF.
> 
> You should exactly come up with:
> - Requirements
> - Applicability statement
> - What problems the current schemes did not solve
> which lead you to suggest the present routing
> scheme.
> - What is the over-head when compared to the other
> existing technologies??? Usegood simulation to prove
> them.
> - A theoretical model to prove its use by means of
> routing problem formulations
> - Some case studies.
> - Study their properties (scalability, flexibility
> and
> extendibility.)
> - What all places it is most useful or waste
> (inter-domain or intra-domain)
> - Does it conform with the architectural principle
> (this is important: e.g.. Scalability alone is not
> the
> reason for intserv non-usage. It did not work within
> boundaries (AS.) alone.It can transcend an
> autonomous
> system boundary and so policy cannot be maintained.
> Hence, it did not support the business models well.)
> 
> 
> Now come to IETF. Give an engineering perspective to
> your routing scheme. Convince vendors to implement
> your routing scheme.
> 
> It is sometimes unfortunate that people just come up
> with some X routing scheme and try to convince
> engineering folks. Some of the IETF works was just
> proposals and hence did not succeed or gave problems
> at the later stage. So do all the above work for
> your
> new scheme and then everyone will accept your
> proposal.
> 
> Read the below book on how well the author approach
> such new schemes. 
>  *G. R. Ash. Dynamic Routing in Telecommunications
> Networks. McGraw Hill, New York, 1998*
> This is the book, which introduced dynamic routing
> schemes. It is not just bunch of ideas but has a
> in-depth analysis of requirements and theory.
> 
> 
> > CSPF (Constraint based shortest path) which is a
> > kind
> > of differential routing. I have some discussion in
> > this thread itself on that respect. 
> > Constraint based routing is modification of
> shortest
> > path alo to account for contraints such as (BW ,
> > QOS,
> > policy). 
> 
> I accept this scheme. There are simulation and
> mathematical work to see its behavior. But what it
> lacks is *deployment* which we cannot help.
> There might be lot of operational and business
> policy
> factors associated.
> 
> > CSPF solution is quite popular many are
> implementing
> > it , but I am not sure deployment and
> > interoperatablity concerns......... CSPF answers
> QOS
> > routing concerns (correct if i am wrong). It is
> not
> > the all of the mechanims proposed are
> failure.......
> 
> Note: I could not resist and hence replied. But if
> your care to respond to this mail, reply to general
> routing discussion than MPLS list.
>

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 05:02:37 -0500

My .02$:

- Senthil.

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 11:05:51 +0200

From  [MPLS-OPS]: MPLS Debacle back to [routing-discussion]:Differentiated Routing, not only plain rambo-SPF

Senthil,
This email of yours as well as your previous one only confirms my statement, that
the entire Internet community  (or at least you and some others) is the prisoner of this rambo-SPF routing algorithm.
All the protocols you have enlisted (...,BW inversion SP,...PNNI,..) and let me also add
the reverse SPF in some multicast models, share this egocentric  SPF view.

I am    N O T     talking just another brand of rambo-SPF.

Also, it wouldn't be helpful to follow your advice (come up with requirements, application statements,...)
because if I did you would read all of it with your SPF-centric view in mind. You even do so now, after
I have explained how each router may aquire the identical view of some road system.

Another analogy: 
When you fly to some meeting place, you may get a flyer-map at the hotel concierge. The flyer-maps may be the same
no matter at which hotel you stay. But, eventually, they have a different "You are Here" markation depending on
the specific hotel. I am looking at the propagated road systems by a commonly shared view first, then I respect the
different "you are here" markation. Rambo-SPF however means:"I am here.I see the world only from my point of view."
Taking into consideration any kind of constraints and whichever weights doesn't change anything of this egocentric
view + behavior with all its disadvantages.

Heinrich

-----Ursprüngliche Nachricht-----
Von: senthil ayyasamy [mailto:[email-masked]]
Gesendet: Samstag, 3. August 2002 09:40
An: venumadhav josyula; Hummel Heinrich;
[email-masked]'; [email-masked]
Cc: Andrew Walding; [email-masked]; [email-masked]
Betreff: Re: AW: [MPLS-OPS]: MPLS Debacle

> See how many
> QoS
> > routing schemes were proposed, researched and not

variants+QoS routing( load sensitive,delay sensitive,
routing+ MPLS based (constrianed or whatever)+ overlay

Most of the above routing schemes are subsets of some

You should exactly come up with:
- Requirements
- Applicability statement
- What problems the current schemes did not solve
which lead you to suggest the present routing scheme.
- What is the over-head when compared to the other
existing technologies??? Usegood simulation to prove
them.
- A theoretical model to prove its use by means of
routing problem formulations
- Some case studies.
- Study their properties (scalability, flexibility and
extendibility.)
- What all places it is most useful or waste
(inter-domain or intra-domain)
- Does it conform with the architectural principle
(this is important: e.g.. Scalability alone is not the
reason for intserv non-usage. It did not work within
boundaries (AS.) alone.It can transcend an autonomous
system boundary and so policy cannot be maintained.
Hence, it did not support the business models well.) 

at the later stage. So do all the above work for your

> Constraint based routing is modification of shortest

I accept this scheme. There are simulation and
mathematical work to see its behavior. But what it
lacks is *deployment* which we cannot help.
There might be lot of operational and business policy
factors associated.

> CSPF solution is quite popular many are implementing
> interoperatablity concerns......... CSPF answers QOS
> routing concerns (correct if i am wrong). It is not
> the all of the mechanims proposed are failure.......

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 12:49:31 +0200

Let me repeat:
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.

Because you mention NP-hardness:
The algorithm I showed last week is very fast and doesn't constitute any performance problem.
BTW: I can likewise provide an (yes, heuristic) algorithm (no, four of them)as to build a list of links which form a ring 
(instead of the smallest size tree) and would interconnect n edge nodes by n links. 
Even for n= 200 (as I did for draft-hummel-n-square-investigations-00.txt) it only takes one or two seconds 
computation time.
Note, it is this notorious traveling salesman problem.To find the absolute best link sequence of the ring
it would take 10**80 years computation time, given that one particular link arrangement can be 
checked within 1 micro-second. 

Heinrich

-----Ursprüngliche Nachricht-----
Von: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:[email-masked]]
Gesendet: Montag, 5. August 2002 12:03
An: Hummel Heinrich
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Betreff: RE: Differentiated Routing, not only plain rambo-SPF

My .02$:

- Senthil.

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 12:49:31 +0200

Let me repeat:

Heinrich

-----Ursprüngliche Nachricht-----
Von: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:[email-masked]]
Gesendet: Montag, 5. August 2002 12:03
An: Hummel Heinrich
Cc: [email-masked]; [email-masked]; [email-masked];

My .02$:

- Senthil.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 07:13:04 -0500

> 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.

> 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.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 07:13:04 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 15:03:43 +0200

Find my lines inserted
Heinrich

-----Ursprüngliche Nachricht-----
Von: Ayyasamy, Senthilkumar (UMKC-Student) [mailto:[email-masked]]
Gesendet: Montag, 5. August 2002 14:13
An: Hummel Heinrich
Cc: [email-masked]; [email-masked]; [email-masked];

HH=> a) With respect to a particular road system X , you may determine a respective overflow road system X-overflow.
        E.g. you may determine by computation the cernel of a smallest size tree being that set of links
        which are used by at least y  s/d-traffic combinations, whereby n < y < n*(n-1); y be a fixed assigned number.
        You may recompute the smallest size tree, but before, you want to mark all the cernel links to DISREGARD.
        Traffic which is about to enter the cernel of X, may be forwarded via X-overflow while changing the
        receive DSCP-x to DSCP-x-overflow. The decission to do so may be based on a currently available traffic load/
        traffic metering information.

      b) Or you generate road systems X0, X1, X2, X3 such that the links of Xi, avoid overlaps with links of Xj, j<i.
         One micro flow uses DSCP x0, the next one DSCP x1,... as to balance the traffic and as to avoid congestion
         in the first place.    

HH=> I am sure that DSCP codepoints can be selected such that the DiffServ and DiffRout aspects can be supported.
     After all, DiffRout will help DiffServ to avoid anomalous behaviour in the first place. 

HH:> There is never a free lunch. But what are a view routing tables compared to the probably much bigger number
of p2p LSPs?

HH=> Help me. I am open:-)

HH=> All I have is this C++-program, written by some students, which I have used already several times
     as to show once this aspect, once that aspect, especially w.r.t. tunneling.

I did explain how to determine that set of links, which forms a tree between some edge nodes.
I mentioned that you have to run Dijkstra n times as to make some preparation. If you hereby apply all
the constraints as well as the specific weights you like to be considered, then the resulting
smallest size tree will suffice them, too.

HH=> Do I have to ? Remember, it is August and time to go on vacation :-)

HH=> If there is enough interest, I would be happy to show this C++-program on work. 
     As I said, it is not yet enhanced with tie breaker rules. But that would be very important as to
     determine the same identical smallest size tree determined b whichever node. If this failed we would
     have to continue with rambo-SPF:-)

HH=> No problem. Be sure, it doesn't run 10**80 years :-)

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 16:14:21 +0200

Jing, 
find my lines inserted
Heinrich

Hummel ,

>         traffic metering information.

what's the meaning of "cernel"? I can't find it in dictionary.  But, if you means overflow those congested traffic to
another path, I think it will do harm to promising of SLA signed. Perhaps what we need is to reroute some part of
traffic to another path with no/less congestion

HH=> Sorry for my bad English: I mean kernel (not cernel).
   But why would it do harm to promising of SLA ? This overflow route may provide the same QoS/SLA !

>          One micro flow uses DSCP x0, the next one DSCP x1,... as to balance the traffic and as to avoid congestion

I don't think load balancing could be achieved by this way, as self-similar and asymetric distribution in internet
traffic
HH=> By utilizing an extra information (i.e. different DSCPs)we are much better of than ECMP, where source/dest. is hashed
     in a poorly way. You really get for free the routing of all packets of a particular microflow along the same route !

> HH:> There is never a free lunch. But what are a view routing tables compared to the probably much bigger number

But the problem is routers have to maintein all information about DSCP they support and propagate them.
HH=> this shouldn't be a big lunch packet, right ?

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 5 Aug 2002 16:14:21 +0200

Jing, 
find my lines inserted
Heinrich

Hummel ,

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 12:48:15 -0400

Senthil &  Shen,

-> HH:> There is never a free lunch. But what are a view routing 
->      tables compared to the probably much bigger number
->      of p2p LSPs?

  You told/questioned about theoretical correctness of 
  DiffRouting approach. Let me tell you in what direction 
  we are moving (practically).

  If you put together everything what is happening in
  IETF WGs you will see that "indirectly" we are doing
  DiffRouting. Believe me...read on...

  Read this simple draft [in IESG last call]
  http://www.ietf.org/internet-drafts/draft-ietf-tewg-te-metric-igp-00.txt

  This draft suggest to use 2 IGP metrics (right now 
  1 in IGP Hop-by-Hop topology info and another in
  IGP-TE info) efficiently to do QoS routing.
  1 metric for Data and another metric for voice.

  What is this finally boil down to - If I provide
  this feature to SPs, think, how are they going to
  use this in DiffServ domain?
  
  Simply, SPs can map 2 different services [example,
  2 different CoS-types] to these different metrics.
  Effectively we *are* doing DiffRouting...previously
  there is no name for it...(and we are getting panicked
  that we are facing a new/unresovable/performace 
  implicated problem here). 

  To extend the idea more (from 2 metrics to n metrics)
  please read draft-fedyk-isis-ospf-te-metrics-01.txt.
  I discussed this with Francois, he said, the above
  draft also is going to get into DiffServ-aware-TE problem
  space.

  Look at this way, DiffServ-Aware-TE is more than
  DiffRouting. DiffRouting is just a subset of what we
  are solving right now.

-> But the problem is routers have to maintain all information 
-> about DSCP they support and propagate them.

  Shen, yes we are flooding all the information about DSCP
  *indirectly*.

-> 1. The diffserv architecture, as of now, defines only 
-> the data plane work.  control plane activities( routing,
-> signaling etc)  are still open questions. 

  With recent changes in TE-WG and MPLS, control plane
  is now aware of DiffServ-Aware-TE. Read...
http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-proto-01.txt

-> Thus said, coming with a new scheme is not a big task,
-> problem space and applicability statement is very 
-> important.

  I agree.

-> I am not asking you to formulate diffrout as an increment 
-> to SPF but just enlighten us *problem* and *need* of 
-> diffrout.

  As a layman (problem statement & need):
  "I (end-user) will be very happy if my voice call over IP
   performs atleast as good as over POTS (proportional to
   what I pay as monthly charges)"
 
  As a technical person (problem statement):
  - Quality of Service to End User
  - End-to-end performance
  - Efficient use of Resources
  - Congestion Avoidance & Control
    ...

  How are you going to solve above problems with out using
  DiffServ-Aware-TE (aka DiffRouting)? I am very glad
  to know your *solution*:
  -  with out letting control plane know
  -  with out propagation DSCP info (directly/indirectly)
  -  with just using SPF (with out CSPF)
  -  with out using MPLS
  . . .

  Thank you.

--
Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:03:50 -0400

Senthil,

-> 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.

  I agree with you here. Yes! there are performance and
  scalability problems if we go for DiffRouting in a 
  hop-by-hop fashion. Then you have to maintain
  different route tables, line rate forwarding issues etc etc.

  That is why we went for source routing (using MPLS-TE).
  That effectively solved the problem of maintaining 
  multiple routing tables. Connection-less to connection-oriented
  move (with small fixed length label lookup) solved the 
  problem of line rate forwarding (directly or indirectly).
  
  Now we are moving towards MPLS-TE with DiffServ.

  Source routing also has scalability issues. This is yet to
  be solved!

-> - 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.

  Weight complexity with performance.
 
-> - end to end: Diffserv is defined only for edge to edge. How will 
-> diffrout behave when considering end to end is still open.

  Yes! This is what I am concerned about.

--
Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:03:50 -0400

Senthil,

  

 

--
Venkata.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:07:10 -0500

There are certain truths to the statements you are making, 
but the conclusions you arrive at from those threads of 
fact are incorrect/flawed. I am still doubtful about its
theoretical correctness leave alone its 
* complexity
* lack of requirements
* duplicating existing functionalities(e.g.ToS routing.)
Just go through *http://www.cs.bu.edu/fac/matta/Papers/jsac95.ps*.
They do for two TOS classes: delay and throughput in a non-FCFS
scheduling environment. you are suggesting for n- classes. 
The paper concludes based on simulations and analytical results
using liapunov functions that there is some reduction in end-to-end 
delay.
So for just coming to one conclusion, the authors have done lot 
of simulation and analytical work. But it is unfortunate that you
are making sweeping conclusions without a valid proof.
 
I will reply detaily later today.But before that clarify 
these points,
- you all accept that diffrout is not going
to solve any problem.
>-> problem space and applicability statement is very
 
- It is complex.
>HH:> There is never a free lunch. But what are a view routing 
>tables compared to the probably much bigger number
>of p2p LSPs?

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:07:10 -0500

- It is complex.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:22:31 -0400

Senthil,

-> Just go through *http://www.cs.bu.edu/fac/matta/Papers/jsac95.ps*.
-> They do for two TOS classes: delay and throughput in a non-FCFS
-> scheduling environment. you are suggesting for n- classes. 
-> The paper concludes based on simulations and analytical results
-> using liapunov functions that there is some reduction in end-to-end 
                                          ^^^^

-> delay.
-> So for just coming to one conclusion, the authors have done lot 
-> of simulation and analytical work. But it is unfortunate that you
-> are making sweeping conclusions without a valid proof.
  
  You misunderstood me. I am not concluding anything. 
  I am giving my own view in a different perspective and 
  letting you know how we can co-relate recent events.

  Let me go through the above paper - I will get back to you.

-> I will reply detaily later today.But before that clarify 
-> these points,
-> - you all accept that diffrout is not going to solve any problem.
                                                        ^^^
  
  Let us see :) You are contradicting your-self. Just in the above
  para you said "SOME reduction in end-to-end performance" and
  again said "diffrout is not going to solve ANY problem".

  If that SOME reduction is tolerable then, I think, we solved
  SOME problem. Thus I can prove that that statement 
  "diffrout is not going to solve ANY problem" is incorrect.

--
Venkata

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:22:31 -0400

Senthil,

-> delay.

  

--
Venkata

---

From: Naidu, Venkata <[email-masked]>
Date: Mon, 5 Aug 2002 14:20:25 -0400

Senthil,

-> delay.

  

--
Venkata

---

From: Naidu, Venkata <[email-masked]>
Date: Mon, 5 Aug 2002 14:20:25 -0400

Senthil,

-> delay.

  

--
Venkata

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:26:46 -0500

>  Now we are moving towards MPLS-TE with DiffServ.
who told you diffserv-aware MPLS -TE scalable? 
Section 4.4 and 3.1 of http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-reqts-05.txt clearly points out the scalability problems.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:26:46 -0500

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:35:38 -0400

Senthil,
 
-> >  Now we are moving towards MPLS-TE with DiffServ.
-> who told you diffserv-aware MPLS -TE scalable? 
-> Section 4.4 and 3.1 of 
-> http://www.ietf.org/internet-drafts/draft-ietf-tewg-diff-te-r
-> eqts-05.txt clearly points out the scalability problems.

  You clipped out my next line. I didn't say that DiffServ-Aware-
  MPLS-TE is scalable. I also said the same thing:
     
  " Source routing also has scalability issues. This is yet to
  be solved! "

  So, are you saying that:
  There is no difference between MPLS-TE and DiffServ-aware-MPLS-TE?
  In other words, are you saying that Differv-aware-MPLS-TE is not
  going solve ANY problem that MPLS-TE alone couldn't solve ?

--
Venkata

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 14:35:38 -0400

Senthil,

     

  So, are you saying that:

--
Venkata

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:49:07 -0500

>again said "diffrout is not going to solve ANY problem".
end to end performance reduction is authors view. My comments were
more particular towards *diffrout* than *ToS routing*. diffrout
is suggesting n-class whereas ToS routing just two classes. you are 
mixing author's ToS scheme with your suggestions. diffrout is not
scalable when compared to ToS routing. So talk about your proposal
(diffrout) than ToS routing.

>"diffrout is not going to solve ANY problem" is incorrect.
which problem you have solved here? If you consider end to end 
delay as major problem that diffrout is going to solve, first let
us work with NSIS group to define the signaling mechanism and define
some per-domain behaviour, develop some inter-domain business models 
and then we will solve the problem of e2e delay across a diffserv 
network.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:49:07 -0500

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:57:01 -0500

> There is no difference between MPLS-TE and DiffServ-aware-MPLS-> TE? In other 
> words, are you saying that Differv-aware-MPLS-TE 
> is notgoing solve ANY problem that MPLS-TE alone couldn't 
> solve ?
I was just talking about diffserv aware MPLS TE which is more related to 
the context of discussion. The authors of diffserv MPLS TE draft discusses 
scalability problems.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 13:57:01 -0500

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 15:33:15 -0400

Senthil,

-> > There is no difference between MPLS-TE and 
-> DiffServ-aware-MPLS-> TE? In other 
-> > words, are you saying that Differv-aware-MPLS-TE 
-> > is notgoing solve ANY problem that MPLS-TE alone couldn't 
-> > solve ?
-> I was just talking about diffserv aware MPLS TE which is 
-> more related to 
-> the context of discussion. The authors of diffserv MPLS TE 
-> draft discusses scalability problems.

  Yes! I am also talking about DiffServ-aware-MPLS-TE.
  In the draft-ietf-tewg-diff-te-reqts-05.txt authors
  clearly mentioned about problem statement and how we
  can benefit from DiffServ-aware-MPLS-TE (even if there
  are some scalability issues). Effectively, authors
  are trying to solve SOME problem - then how can 
  you can say that DiffServ-aware-MPLS-TE (aka DiffRouting)
  is not going to solve ANY problem.

  Scalability issues in TOS Routing are different
  from scalability issues in DiffRouting (if you consider
  TOS routing is applicable in traditional hop-by-hop
  routing case and DiffRouting is applicable in todays
  source routing cases).

  Finally, let me conclude what I agree and disagree
  with you.

  What I agree:
  - None of these approaches [traditional TOS-Routing or
    DiffRouting (DiffServ-aware-MPLS-TE)] really solve
    end-to-end QoS/Performance. I already expressed this
    concern to Fred Baker (which he concluded that as
    an open ended question) - which is fine!
http://www1.ietf.org/mail-archive/working-groups/routing-discussion/current/
msg00060.html

  - None of the above approaches are complete. They have
    some common and some different issues - for example
    scalability etc etc

  What I don't agree (my view):
  - Just because a solution has scalability issues doesn't
    mean that that solution is not going to solve ANY 
    problem.

  - Diffserv-aware-MPLS-TE is trying to solve different problems
    which we couldn't solve with traditional routing approaches
    *easily* in the past.

  - We are trying to solve (we will solve) those scalability
    issues in source routing (using hierarchical TE etc etc)
    in future.

  Do you agree? If not let me know - let us discuss :)

  If you still feel that DiffRouting is not going to solve 
  ANY problem then I will ask authors of 
  draft-ietf-tewg-diff-te-reqts-05.txt (for clarification).
  
  Finally, you didn't tell me in what other approaches
  we can solve the same issues that the DiffServ-TE is
  trying to solve (with out letting control plane know,
  with out CSPF, with out connection-oriented MPLS etc etc).
  
--
Venkata

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 5 Aug 2002 15:33:15 -0400

Senthil,

  What I agree:

  
  
--
Venkata

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 19:36:15 -0500

>   I am also talking about DiffServ-aware-MPLS-TE.
Diffserv aware MPLS TE draft doesn't call for bar on SPF. But
you people are keeping that as a subject and discussing.

Some of the definitions and road examples of diffrout doesn't fit 
the bill of diffserv aware MPLS TE. 

As of now, whatever techniques standardized by TE-WG, is applicable
only for intra-domain (including diffserv-aware TE.) But read some 
of your mails, you talk about end to end issues.

Do you get your problem now? If you are not clear with your problem
statement, you will tent to make deviating observations.

If Diffserv-aware-MPLS-TE = diffrout, I am in full agreement with some 
of your views. But remember again, you made some comments about end to end 
delay issues which even Faucheur et all won't accept. 

Hummel, was your original proposal same like Diffserv-aware-TE. I thought
it was different.

>   routing case and DiffRouting is applicable in todays

Yup ..its different. you have used some of the ToS routing 
conclusions for claiming diffrout scheme and hence, i made that
comment regarding scalability. 

>    mean that that solution is not going to solve ANY 

Sorry for making such a statement. But you should also agree 
that, you did not still clearly state *why we need diffrout?*

>  with out CSPF, with out connection-oriented MPLS etc etc).
First of all control plane work in Diffserv is incomplete. 
what you want to do with *diffrout*-QoS-Routing, sneak-around 
the congestion-area routing, and traffic balanced routing.

Let me suggest you a simple technique: Use *explicit routing* of
MPLS which is the simplese one for doing sneaking around work.

Doing dynamic QoS routing is very difficult and operators 
generally dont prefer. But this is surely not a good argument :-).
i will support diffrout if you just explain me *why we need 
diffrout*. I am reading all the 14 mails regarding diffrout but 
still couldn't get a correct problem statement.

In the corner, I am too advocating a new idea which is  contradictory
to diffrout. By taking SPF into account, an effective load balancing 
can be done in diffserv architecture. I will get back to you once i get 
done with an analytical model.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 19:36:15 -0500

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 22:00:16 -0500

> i think that some form
> of cooperative path computation strategy 
> ( e.g.  diffusive computational nash game, or
> epidemic/gossip tabu search, or whathave you) 
Cooperative path computation are highly theoretical at
the present stage. I think there might be many
assumptions and approximations to prove such strategies.

take one simple example: Throup et all describe 
methods for optimizing OSPF weights by using heuristic methods
..esp local search hueristics (tabu...) But in reality, people
generally use standard heuristics (like Weight inversely propotional
to capacity.) So i think as a least option we may choose some standard 
heuristic assumptions for solving such co-operative path computations.
So using tabu search methods are sometimes not practical.

>might yield
> more novel solutions than incremental techniques rooted in
> the 35 year old stuff we've (oops, s/we/me) tended to get
> stuck on....

Solutions might be novel. We introduced IPv6 long before but still
we could not transfer to new structure all together. we go for 
increment methods like CIDR, NAT, double stack, and ALG than transition
to a new addressing structure. So, it is always advisable to do some
incremental techniques than novel solutions. But, if you are proposing 
new structure, first we should address flag day  problem will 
trasitioning. i dont think any new systems does this work.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Mon, 5 Aug 2002 22:00:16 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 6 Aug 2002 08:39:10 +0200

>   implicated problem here).
Ibrahim wrote:

How is "DiffRouting" different from
old Type-of-Service (ToS) routing?

My answer:
By constructing multiple road systems, which  eventually are even constructed in awareness of
road systems constructed before (e.g. overflow road system X-overflow w.r.t. road system X)
and to lock traffic into some road system so that it is kept out of the way from other traffic. It may mean not to
take the shortest path for the individual micro flow.

Heinrich

http://www.faqs.org/rfcs/rfc1349.html
http://www.cs.bu.edu/fac/matta/Papers/jsac95.ps

ibrahim

--
Ibrahim Matta       Dept of Comp Sci, 111 Cummington St, MCS-271
[email-masked]     Assistant Prof, Boston Univ., Boston, MA 02215
Tel: (617)358-1062, Fax: (617)353-6457, URL: www.cs.bu.edu/fac/matta/

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 6 Aug 2002 08:39:10 +0200

Ibrahim wrote:

My answer:

Heinrich

ibrahim

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 6 Aug 2002 09:31:11 +0200

I am really surprised that the need for having several routing table is a big (scalability) issue:
(BTW:Logically it takes separate routing tables, one per DSCP. But you may as well maintain one routing table
 and search the next hop entry also based on the DSCP)

IMO stateless DiffRout-Forwarding is more scalable than MPLS or RSVP.

However,if the size of the routing table is an issue, then why wasn't it an issue so far:
Each ingress node needs to know the egress node before setting up the respective next hop entry in the routing table.
So why doesn't the IP header contain a field for the destination router address. It would allow to keep the routing tables
small: one single next hop entry w.r.t. each destination router would be sufficient.
Of course, it would be rediculous to expect any change in IPv4. But why wasn't this an issue for IPv6 ?
When IPv6 was born, I guess there have already been routing tables of respectful size.
Can anyone tell me?

Heinrich

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Montag, 5. August 2002 21:33
An: 'Ayyasamy, Senthilkumar (UMKC-Student)'; Hummel Heinrich
Cc: [email-masked]; [email-masked]; [email-masked];

Senthil,

  What I agree:

  
  
--
Venkata

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 6 Aug 2002 09:31:11 +0200

Heinrich

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Montag, 5. August 2002 21:33
An: 'Ayyasamy, Senthilkumar (UMKC-Student)'; Hummel Heinrich
Cc: [email-masked]; [email-masked]; [email-masked];

Senthil,

  What I agree:

  
  
--
Venkata

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 6 Aug 2002 03:12:37 -0500

> I am really surprised that the need for having several 
> routing table is a big (scalability) issue:
> (BTW:Logically it takes separate routing tables, one per 
> DSCP. But you may as well maintain one routing table
  Yes diffserv forwarding is less stateful when compared to MPLS 
or RSVP. But that has nothing to do with scalability problems in maintaining 
multiple routing tables. 
There are scalability issues wrt single routing table itself. People are still 
working on scalable solutions for mimizing the overhead, wrt adding mechanisms 
like accounting and other valued added measurement functions, which requires 
processing of pkts at line rate. So i am guessing, scalablity associated with 
multiple routing tables, will be a long shot.

See again you have started with diffrout, then it was changed to diffser-aware-TE 
and now mechanisms for basic diffserv arch. 

> Each ingress node needs to know the egress node before 
> setting up the respective next hop entry in the routing table.
> So why doesn't the IP header contain a field for the 
> destination router address. It would allow to keep the routing tables
> Of course, it would be rediculous to expect any change in 
> IPv4. But why wasn't this an issue for IPv6 ?

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 6 Aug 2002 03:12:37 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 6 Aug 2002 12:03:02 +0200

My answer:
DiffRout is definitively different.

My motivation and my key thoughts to open this discussions have been:
- combine the best of Intserv/MPLS and Diffserv and as a result do stateless IP forwarding but get
     what  Intserv/MPLS are providing: Qos/BW/Policy/Traffic balancing/rerouting.

- therefore construct road systems and do IP forwarding/routing also based on DSCP.

- the road systems may have assigned bandwidth. This is reasonable/feasable because some traffic can really
  be locked into some slim road system (smallest size tree, smallest ring) just like MPLS traffic can be locked into
  some LSP. Whereas with rambo-SPF bandwidth assignment makes no sense as the sum of all
  shortest path trees computed by all the nodes would span the entire network, i.e. spread traffic all over it.
  The price for staying within some road system should be acceptable: Eventually, make a few hops more.
  Based on my computations, the smallest size tree may be smaller than the avarage shortest path tree by 15-20 %. 
  So I think the detour for the packets will not be very big either.   

- be guided by what you can observe on daily road traffic: Especially in the U.S. there are so many ramp-based
  road junctions, which are more impressive than any traffic light controlled junction, so that motor-cyclists may
  jump the queue of waiting cars (=DiffServ) if the traffic light is red. 
  There are so many observations that can be made watching how the traffic is managed for cars, 
  trains, airplanes, pedestrians, etc. We all are used to it and don't discern extra smartness in it. However there is.
      
- and I realized what is the big obstacle: Yes it is this rambo-SPF routing paradigma. It does not represent the  
  surveillant view, only the egomanic view, combined with the hope that in total you get best results because 
  "the streets are emptiest when each car takes the shortest route":-). 

Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Mon, 12 Aug 2002 17:02:57 +0200

Jing,
Let me recapture and use the following DSCPs: 
DSCP-Gold-1st, DSCP-Gold-2nd, DSCP-Silver-1st,DSCP-Silver-2nd,DSCP-Bronze-1st,DSCP-Bronze-2nd. 

DSCP-Gold-1st and DSCP-Gold-2nd shall trigger DiffServ Gold-SLA handling.
DSCP-Silver-1st and DSCP-Silver-2nd shall trigger DiffServ Silver-SLA handling.
DSCP-Bronze-1st and DSCP-Bronze-2nd shall trigger DiffServ Bronze-SLA handling. 

They shall as well identify road systems: 
DSCP-Gold-1st, DSCP-Gold-2nd, DSCP-Silver-1st,DSCP-Silver-2nd,DSCP-Bronze-1st,DSCP-Bronze-2nd - built in this
sequence. Hereby each road system is based on what has been left over by the previously built road systems (in terms of
bandwidth).

Gold:  A smallest size tree of toll roads, highways, state roads, country roads.
Silver:A smallest size tree of highways, state roads, country roads.
Bronze:A smallest size tree of state roads, country roads, and highways only if no path otherwise.
 
QoS parameters (speed, packet loss rate, MTU size,..) may define the type of road.

1st and 2nd road system may be different at least  w.r.t. their kernel parts. (The kernel part be that 
center of the smallest size tree, which is used by at least m ingress/egress combinations).
Either traffic starts out with a) proper DSCP-Y-1st, resp. DSCP-Y-2nd, or b) is  changed from DSCP-Y-1st to
DSCP-Y-2nd at the rim of the kernel if some current traffic load information advises so. I prefer a) and if possible such
that any microflow will entirely take one single route.

Jing, you are mentioning two aspects, namely stability and extensibility.
Stability: 
We may toss a dice at the ingress,i.e. determine a random number Y between 0.0 and 1.0. If  
0.0<= Y < a, then we use DSCP-Y-1st, if a<= Y < 1, then we use DSCP-Y-2nd. The real number a should be such
that we avoid/dissolve some congestion and do not relocate it. At low-traffic times a is equal 1. But for the busy hour
determining value a  will be a very interesting topic. 
If any  University folks were interested in doing simulations as to determine value a for all ingress/egress combinations
and for all three SLAs, I would be happy to exchange more thoughts and details on it (so far I have always deferred it).
Especially, it would be interesting to get comparable results between what I called "Orchestrally Conducted Traffic" and
OMP.
However we would be leaving  the DiffRout-track of thoughts. Therefore we should say: this is out of scope of this thread. 
It may only be addressed by some other thread.

Extensibility:
So far I have no solution, on how to determine a smallest size tree made out of OSPF-links and EBGP/IBGP-hops.
BTW:
It seems to be appropriate to focus on  smallest size tree road systems, at least for some time, although ring and
somehow meshy road systems might also be considered. 

Can anybody contribute some  solution ? I think, it must be an identical tree of BGP-hops. Only all edge routers of the
same OSPF network must aquire the completely identical tree. Somehow:-)

Heinrich 

-----Ursprüngliche Nachricht-----
Von: shen jing [mailto:[email-masked]]
Gesendet: Dienstag, 6. August 2002 15:04
An: Hummel Heinrich
Cc: [email-masked]; [email-masked]
Betreff: Re: Differentiated Routing, not only plain rambo-SPF

Hi Hummel,

As DSCP is used for packet queueing in routers,  there may be many types of  queueing mechanism for scheduling of
different classes.

As mentioned in previous message that when overflow/congestion happens along some path, the flow of the same  DSCP
could be overflowed onto other path (?) or it could be dispersed onto multiple paths computed.
This means, if we want to adapt to time-varying network status  LSA must be triggered by overflow of any queue on its
outgoing interface. Because internet traffic's self-similarity characteristics and "heavy-tailed" flow sized distribution,
  we
could not expect the network status maintains a stable status. That is,  routing behavior have to be adjusted frequently.
Right ?  CBQ or the like may adjust the resource allocated dynamically according to load on routers, how could that be
reflected ?   I think, all these factors will do harm to routing stability and extensibility, esp. when we consider
inter-AS routing.

Well, I think some time to read those paper suggested.

--
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:07:40 +0200

Jing
see my inserted comments.
Heinrich 

Hummel,

> QoS parameters (speed, packet loss rate, MTU size,..) may define the type of road.

Do you means to restrict DSCP to be 3bits? 
HH=> No. In general we may  correlate several, e.g. m,  "gold-like" DSCPs 
          a) to their currently defined "gold-like" DiffServ functionality
          and b) to one Gold-1st road system,
    
     Furthermore, we may identify m additional and  suitable  DSCPs which shall trigger the same
     "gold-like" DiffServ functionality like above, but which are correlated to Gold-2nd road system.

> that any microflow will entirely take one single route.

So, that means to use alternative path for overflowed traffic?  In fact,
someone has proposed similar

method. Perhaps you are interested in the following paper:

http://www.cs.virginia.edu/~rv3s/pubs/compnet_paper.pdf 

HH=> I will go and read this paper.
     I am not surprised and I really welcome that there are others who write such papers.
     I only believe, that sqeezing/locking some traffic into e.g. some smallest size tree-road system
     enables much more effectiveness, both for the better and the worse:
     for the worse: Best-Effort-Traffic may even be handled worse, if locked into an overcrowded road system of
                    bad condition.
     for the better: Gold-traffic will be handled better, if best roads are available and if Best-Effort-Traffic is
                     kept out of the way.  

> 
>
> Stability:
> We may toss a dice at the ingress,i.e. determine a random number Y between 0.0 and 1.0. 

I think this determines when a second path is adopted for traffic
routing, in fact we do not
need to use a random number if MPLS is used. At this situation, I think
what we need is to 
monitor load on a LSP, if the load is more than 70% of the effective
bandwidth another LSP is
adpoted. If distributed routing is used ( as that of current IP
network), traffic dispersion 
have to be triggerred by heuristic method mentioned by you.

HH=> Fine.

> So far I have no solution, on how to determine a smallest size tree made out of OSPF-links and EBGP/IBGP-hops.

As I think, a routing system built on time-varying network status will
do harm to both
stability and extensibility, because it could not be expected to all
routers converge to the same 
point within a short time period.

HH=> We should really ask students to program simulations and to investigate whether it will harm or improve stability. 

Some others have been working on resource management in DiffServ
networks, the page located 
at:

http://standards.ericsson.net/rmd/

In deed, I'm very interested in this idea but I think it need more
clarification.

HH=> I will read this paper, too. But again: If you have (at least)  N shortest path trees rooted at  N ingress edge router,
they will disperse traffic all over the network and it is fairly vague what bandwidth on which link shall be reserved.
Whereas if you lock all this traffic into one single  smallest size tree, you may allocate bigger BWs to fewer links.

Hope to hear from others.
HH=> Hope so, too.

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:07:40 +0200

Jing

Hummel,

    

HH=> Fine.

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:24:14 +0200

Jing,
Right this moment I looked at new email-thread on MPLS list "fast re-route merging".
What popped up in my mind:
The smallest size tree road system is, in practice, BI-DIRECTIONAL. It should be feasable to
crank back:  Either   IP-in-IP or some new TYPE information may be applied.The packet's source and destination 
address fields may be exchanged at the point of congestion. The packet may be returned to where the associated overflow road system can be entered. There, source and destination address fields have to be exchanged once again and the packet may be
forwarded with the alternate DSCP along the associated alternate road system.

Wouldn't this be a nice add-on ?

Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:24:14 +0200

Jing,

Heinrich

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Aug 2002 09:48:30 -0400

Hummel Heinrich wrote:

> crank back:  Either   IP-in-IP or some new TYPE information 
> may be applied.The packet's source and destination 
> address fields may be exchanged at the point of congestion. 
> The packet may be returned to where the associated overflow 
> road system can be entered. There, source and destination 
> address fields have to be exchanged once again and the packet may be

I'm no expert in PNNI, but isn't this exactly what it does when it cannot meet the call setup QoS parameters along the shortest path route?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Aug 2002 09:48:30 -0400

Bert

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:56:53 +0200

Bert,
yes,it is similar;
but here it is about state-less IP forwarding, i.e. about forwarding the individual IP packets, without any
RSVP path and without any MPLS path.
Heinrich

-----Ursprüngliche Nachricht-----
Von: Manfredi, Albert E [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 15:49
An: 'Hummel Heinrich'
Cc: [email-masked]'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF

Bert

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 15:56:53 +0200

Bert,
yes,it is similar;

-----Ursprüngliche Nachricht-----
Von: Manfredi, Albert E [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 15:49
An: 'Hummel Heinrich'
Cc: [email-masked]'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF

Bert

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 10:00:51 -0400

Hummel & Bert,

  FYI-
http://www.ietf.org/internet-drafts/draft-iwata-mpls-crankback-04.txt

http://www.ietf.org/internet-drafts/draft-ietf-mpls-te-feed-04.txt

--
Venkata.

-> -----Original Message-----
-> From: Manfredi, Albert E [mailto:[email-masked]]
-> Sent: Tuesday, August 13, 2002 9:49 AM
-> To: 'Hummel Heinrich'
-> Cc: [email-masked]'
-> Subject: RE: AW: Differentiated Routing, not only plain rambo-SPF
-> 
-> 
-> Hummel Heinrich wrote:
-> 
-> > Jing,
-> > Right this moment I looked at new email-thread on MPLS list 
-> > "fast re-route merging".
-> > What popped up in my mind:
-> > The smallest size tree road system is, in practice, 
-> > BI-DIRECTIONAL. It should be feasable to
-> > crank back:  Either   IP-in-IP or some new TYPE information 
-> > may be applied.The packet's source and destination 
-> > address fields may be exchanged at the point of congestion. 
-> > The packet may be returned to where the associated overflow 
-> > road system can be entered. There, source and destination 
-> > address fields have to be exchanged once again and the 
-> packet may be
-> > forwarded with the alternate DSCP along the associated 
-> > alternate road system.
-> > 
-> > Wouldn't this be a nice add-on ?
-> 
-> I'm no expert in PNNI, but isn't this exactly what it does 
-> when it cannot meet the call setup QoS parameters along the 
-> shortest path route?
-> 
-> Bert

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 10:00:51 -0400

Hummel & Bert,

  FYI-

--
Venkata.

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 16:06:19 +0200

Venkata,
yes I know. And let me add my personal feeling:
I think Iwata's draft should become a working group draft. It is overdue.
Heinrich

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 16:01
An: 'Manfredi, Albert E'; 'Hummel Heinrich'
Cc: [email-masked]'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF

Hummel & Bert,

  FYI-

--
Venkata.

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 16:06:19 +0200

Venkata,

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 16:01
An: 'Manfredi, Albert E'; 'Hummel Heinrich'
Cc: [email-masked]'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF

Hummel & Bert,

  FYI-

--
Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 10:09:50 -0400

Heinrich,

-> yes,it is similar;
-> but here it is about state-less IP forwarding, i.e. about 
-> forwarding the individual IP packets, without any
-> RSVP path and without any MPLS path.

  Oh! Ok...you would like to do Crankback in
  connection less IP environments?!?

  In such a case, you might find below paper interesting:
http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-latest.pdf

  There was some discussion in E2E list regarding
  pros & cons of this approach. I couldn't find the URL
  but I vaguely remember that the subject of the discussion
  is "EC++N" or something like that...

--
Venkata

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 09:27:57 -0500

> I'm no expert in PNNI, but isn't this exactly what it does 
> when it cannot meet the call setup QoS parameters along the 
> shortest path route?
 Hi, even some of NSIS and resource management functions 
looks like the same. But that doesnt mean that we dont have 
to come up something new. But a clear line between the analysis 
is essential. I am much less interested in taking MPLS into the 
picture. Of from a purely research angle, analyzing with DSCP 
alone works fine. We can introduce some sort of non-cooperative 
routing which is the default scheme for many peer to peer 
communications. A lot of heuristics based, query based, index baed 
algorithms can be done which can some day become an alternative to 
SPF. But looking from a engineering perspective, no doubt SPF will 
rule.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 09:27:57 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 16:40:25 +0200

Senthil,

Here it is about fast rerouting of IP packets by cranking back to that router where the overflow road system 
may be entered.

You are mentioning NSIS. 
NSIS is interested in two-way applications and would benefit if the two inverse directed pathes are identical.
This is automatically provided by using a smallest size tree road system.

I think the more we debate, the more usefull things we will discover:-)

Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 16:40:25 +0200

Senthil,

You are mentioning NSIS. 

Heinrich

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:01:38 -0400

Heinrich,
 
-> I think the more we debate, the more usefull things we will 
-> discover:-)

  Yes! you are right :) But we can't keep on discussing or
  learning things... :-)

  Average age of a person who can make significant 
  novel contribution to any field will increase in 
  future years. Next generations will definitely 
  suffer & struggle for existence in the changing 
  facets of science & technology (unless intellectual 
  power of humans increase by birth). 

  To make it crystal clear, now (in 2002) it is 
  enough to invent something new/beneficial technology,
  if we follow past work done by few Yakov Rekhters.
  But in future, an average inventor must know
  thousands of such Yakov Rekhters works. Is that 
  possible in a life span ? :)

  It is highly unlikely that a person can invent 
  something new with out complete understanding of 
  relevant past work done on any subject.

  I am really worried...

--
Venkata.

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:01:38 -0400

Heinrich,

  I am really worried...

--
Venkata.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 09:40:17 -0500

> http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
 I have studied this paper. Your are mis-interpreting here. The RPI
paper is an increment to OSPF or BGP for some traffic engineering
functionalties. It doesnt require signaling whereas, diffrout 
requires signaling. Also, we are taking more from a diffserv 
point of view.
 As i told, routing in peer to peer networks and some overlay 
systems can use diffrout concept. We can explore certain non-
cooperative algorithms for an alternative to SPF. But as mentioned
before, this will not work out if we see from an engineering 
perspective.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 09:40:17 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:05:54 +0200

I am sorry, but there is no signalling (like RSVP, RSVP-TE, CR-LDP) for doing DiffRout.

Based on the information exchanged by the routing protocol (like OSPF) all nodes should be able to
compute the same smallest size tree which interconnects the edge routers (those with attached users or attached external interfaces), and which complies to some specific constraints (QoS/BW/Policy,eventually avoiding overlaps with other 
road systems),and which are associated to the same DSCP(s).  // plural: see my  previous email from today

But there is no signalling as to "establish the DSCP-associated road system" !!!

However,it would be a fancy but completely new task to determine and establish an MPLS-road system,
which may lock MPLS-traffic into such slim Smallest Size Tree graphs. See all my work on establishing
the "road systems for VPNs" based on elementary+ hierarchical LSPs.

Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:05:54 +0200

Heinrich

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 10:13:27 -0500

> CR-LDP) for doing DiffRout.

 My mistake here.. But diffrout has few goals in common with
the RPIs *BANANAS* traffic engineering framework but sometimes
complimentary too. The best suggestion might be ..why cant 
you come up with some very rough draft version.So that, we 
can be clear that we are discussing the same scheme. I have 
one picture of diffrout, some others think that as diffser-TE 
and so , it is better if we have some notes before discussion.

> compute the same smallest size tree which interconnects the 
> edge routers (those with attached users or attached external 
> interfaces), and which complies to some specific constraints 
> (QoS/BW/Policy,eventually avoiding overlaps with other 
> road systems),and which are associated to the same DSCP(s).  
> // plural: see my  previous email from today
> 
> However,it would be a fancy but completely new task to 
> determine and establish an MPLS-road system,

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 10:13:27 -0500

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:16:10 -0400

Senthil,

-> > -> yes,it is similar;
-> > -> but here it is about state-less IP forwarding, i.e. about 
-> > -> forwarding the individual IP packets, without any
-> > -> RSVP path and without any MPLS path.
-> > 
-> >   Oh! Ok...you would like to do Crankback in
-> >   connection less IP environments?!?
-> > 
-> >   In such a case, you might find below paper interesting:
-> > http://www.ecse.rpi.edu/Homepages/shivkuma/research/papers/te-
-> > latest.pdf
->  I have studied this paper. Your are mis-interpreting here. The RPI
-> paper is an increment to OSPF or BGP for some traffic engineering
-> functionalties. It doesnt require signaling whereas, diffrout 
-> requires signaling. 

  Heinrich is talking about connection-less, no RSVP, no MPLS
  signaling. I just pointed a *relavent* paper. 
  
  You can find solution to any problem in multiple ways. 
 
  The problem in hand is:
  - Bypass congestion area *effectively* 
    using best of today's technologies
  - Effecient utilization of resources 
  - Fast forwarding
  - QoS (end-to-end perspective)
    etc etc

  IMO, after working for many years in MPLS & relavent technologies,
  I am convinced that MPLS will solve most of the problem we couldn't
  solve in the past *effectively*. Ofcourse, there are some issues
  with MPLS, still, I think, we can solve most of the above issues 
  very efficiently using MPLS than traditional IP routing.

  That is why I am arguing that, what ever problem in hand, can be
  solved by recent advancements in MPLS. Let us not go back to the
  past where we tried to achieve things in connection-less IP 
  environments.

  The work done by RPI guys is something similar to what Heinrich
  is discussing. Especially, section 3.1. Interested people can
  compare/contrast similar work done in the past (like above paper).

--
Venkata

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:16:10 -0400

Senthil,

  
 
  The problem in hand is:

--
Venkata

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:19:26 -0400

-> The best suggestion might be ..why cant 
-> you come up with some very rough draft version.So that, we 
-> can be clear that we are discussing the same scheme. I have 
-> one picture of diffrout, some others think that as diffser-TE 
-> and so , it is better if we have some notes before discussion.

  I completely agree.

--
Venkata

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Aug 2002 11:25:47 -0400

> and so , it is better if we have some notes before discussion.

My reading of diffserv and diffrout is that even if the basic concepts don't require signaling, a signaling protocol will need to be added to make these schemes workable. In diffserv, for example, the per-hop or per-domain behavior associated with any given DSCP will only be valid within certain traffic load limits. The fact that diffserv does not address exactly how those load limits are maintained, other than to mention SLAs, does not mean that _some_ signaling scheme won't be required to make the system work.

Also, I don't believe the Iwata draft is stateless crankback? Maybe I misunderstood, and no one claimed that.

If you're dealing with LSPs, you're dealing with stateful routing, no?

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 13 Aug 2002 11:25:47 -0400

Bert

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:24:59 +0200

Venkata,
We have only discussed for three weeks and have just scratched a little bit on the
disadvantages of SPF. Most of it in the light that real road traffic won't be managed
based on such egocentric view. We are about to look at the existing IETF concepts and will
certainly discover a lot of things which can be improved, simplified, enabled.

Heinrich

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 17:02
An: 'Hummel Heinrich'; 'Ayyasamy, Senthilkumar (UMKC-Student)';
Manfredi, Albert E
Cc: [email-masked]; [email-masked]'
Betreff: RE: AW: Differentiated Routing, not only plain rambo-SPF

Heinrich,

  I am really worried...

--
Venkata.

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:24:59 +0200

Venkata,

Heinrich

-----Ursprüngliche Nachricht-----
Von: Naidu, Venkata [mailto:[email-masked]]
Gesendet: Dienstag, 13. August 2002 17:02
An: 'Hummel Heinrich'; 'Ayyasamy, Senthilkumar (UMKC-Student)';
Manfredi, Albert E

Heinrich,

  I am really worried...

--
Venkata.

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 10:33:38 -0500

> My reading of diffserv and diffrout is that even if the basic 
> concepts don't require signaling, a signaling protocol will 
> need to be added to make these schemes workable. In diffserv, 
> for example, the per-hop or per-domain behavior associated 
> with any given DSCP will only be valid within certain traffic 
> load limits. The fact that diffserv does not address exactly 
> how those load limits are maintained, other than to mention 
> SLAs, does not mean that _some_ signaling scheme won't be 
> required to make the system work.
   The fact is: we have defined diffserv only for data plane.
so, it doent mean we dont require signaling. Some of the next
steps for diffserv arch, they 
 - have to be defined end to end.
 -  signaling mechanism to support end to end 
 - Inter-domain business models.
so my comments with respect to diffserv is that it requires
signaling. I dont know about diffrout ..only hummel has to 
tell..

http://www.packetdesign.com/publications.html has a recent 
survey paper by Brian and  Kathie. Read them to get a picture. 

> 
> Also, I don't believe the Iwata draft is stateless crankback? 
> Maybe I misunderstood, and no one claimed that.
>

---

From: "Ayyasamy, Senthilkumar (UMKC-Student)" <[email-masked]>
Date: Tue, 13 Aug 2002 10:33:38 -0500

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:38:19 +0200

The best suggestion might be ..why cant 

Certainly. It will be my pleasure to write a draft on this topic.
The day after tomorrow I will go on vacation. So it may take a little while :-)
Heinrich

---

From: Hummel Heinrich <[email-masked]>
Date: Tue, 13 Aug 2002 17:38:19 +0200

---

From: "Naidu, Venkata" <[email-masked]>
Date: Tue, 13 Aug 2002 11:19:26 -0400

I completely agree.

--
Venkata

---

From: Hummel Heinrich <[email-masked]>
Date: Wed, 14 Aug 2002 14:47:24 +0200

Let's assume there are two Smallest Size Tree road systems X1 and X2. X2 detours/avoids the kernel links of X1.
For some source/destination node pair the total pathes may be different. Or only the section in the middle is different.
Or only a section close to the source (or close to the dest.) is different. Whatever applies:
From the point of congestion on road system X1 the packet my crankback (hereby source and dest. address are swapped)
to that first node which is also part of X2.
There  source and dest. address are swapped again,  DSCP-X1 is replaced by DSCP-X2 and the packet is  moved forward 
via X2.

Heinrich

-----Ursprüngliche Nachricht-----
Von: shen jing [mailto:[email-masked]]
Gesendet: Mittwoch, 14. August 2002 14:21
An: [email-masked]
Cc: 'Hummel Heinrich'; [email-masked]'
Betreff: Re: AW: Differentiated Routing, not only plain rambo-SPF

The discussion you mentioned is that of congestion removement by e2e
mechanism  or by routing. Professor Crowcroft proposed a method
named ECN++ which trigger a new path that acts when ECN bit is set 
in packet header.

-- 
Jing Shen

State Key Lab of CAD&CG

Tel: +86-571-87932423
Mobile: (0)13516813753