Re: PQC and QOSPF

[Masataka Ohta <[e-mail]>]

Yao-Min;

> > > these messages follow the direction of a flow,
> > > only downstream routers receive resource reservation
> > > info of upstream routers but not the other way
> > > around.  The problem with this is that upstream
> > 
> > Yes, it makes the QOS routing a little more stable and is not a problem.
> 
> Could you elaborate on the stability part? 

Underestimation of down stream resource makes the current path
(up stream) preffered.

> As for "not a problem" part, 
> I hope I understand the protocol correctly but it 
> seems there could be a potential problem.  Consider 
> the following example: a bandwidth of b1 is reserved
> for a multicast flow on the path S--A--B--C--R1. 

OK. But note that you can't scalably propagate resource information
about all the receivers of the multicast.

> Using PQC, router A considers link (B,C) 
> has only available bandwidth b2.  On the 
> other hand, router C can 
> "correct" the link bandwidth to b1+b2 as far 
> as computing the route for the flow is concerned. 
> Now suppose a new receiver R2 would like to join 
> the multicast tree and links (A,R2) and (C,R2)
> both exist (see Figure below).
> 
> S--A--B--C--R1
>     \   / 
>      \ /
>       R2

OK.

> Since router A thinks the available bandwidth b2 
> of (B,C) is insufficient (recall b2<b1), it 
> adds branch (A,R2) for the new multicast tree 
> but router C may compute (C,R2) to reach  
> the new receiver.  So we have an inconsistent 
> calculation of the new multicast tree. 

Wrong.

As the title of the paper says, routing is hop by hop.

Neither A nor C are volunteers to calculate the tree. They just
route RESV requests from down stream to upstream.

So, first, R2 joins a group with best effort. Then, PATH will
come and R2 can now QoS route RESV to A or C and a branch is added.

That's all.

> My main concern is that a very fundamental 
> premise of link state routing algorithm is 
> that all routers see the same network status
> (link states); or one could say all routers
> should have consistent link state databases.  
> PQC, by only notifying downstream routers the 
> reservation status of upstream routers, seems
> to break this premise.   

Yes, it is consistent.

The consistency requirement of any hop-by-hop routing, including but not
limited to LS one, is that the best path computed at some hop should
remain best at the next hop.

As I said "stable", this lack of information keep making the
best path best.

Also, the property of any flooding based algorithm, including
but not limited to that of *OSPF, is that all the perticipants
are deliverd the same data (though with some delay), which
is also the case with PQC.

> > Note that, to assist dynamic rerouting, it reduces rerouting delay, if
> > upstream, NOT DOWNSTREAM, link state of the current path is carried
> > back in RESV, which is an extension to PQC I'm thinking about now.
> 
> Are you saying that instead of using the _next_ refresh PATH 
> message to propagate the resource reservation info, we use 
> _current_ RESV so that we can reduce information propagation
> delay? 

No, it is a little more complicated problem.

In your previous figure, let's assume R1 is the only receiver. Then,
if A-C goes down and A-R2-C is the only available path from S
to R1, QoS routing at R2 should be able to know the corrected
link state of S-A, which can be suplied by RESV from C copied
from old PQC info in PATH.

							Masataka Ohta