Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking

From: [email-masked]
Date: Wed, 25 Feb 2004 08:44:31 +0100

Hi Cheng Hong,

Thanks for your reply. Please see my comments inline.

Sven

"Cheng Hong" <[email-masked]> on 25/02/2004 07:27:10

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL, <[email-masked]>
cc:    "'McDonald, Andrew'" <[email-masked]>, "'Georgios
       Karagiannis'" <[email-masked]>
Subject:    RE: [NSIS] QoS NSLP open issue on error cases with QSPEC
       stacking

Hi Sven, and all,

Please see some comments below:

<snip>
> 1. Should a QNE attempt to recover from an unrecognised QSPEC
> stack ...
>       a. ... in addition to sending an error message upstream?
>       b. ... instead of sending an error message upstream?
> Suggestion: yes, in addition to sending an error

Does this also depend on what the error message contains and how the QNE
peer responds to the error message? If the error message would simply cause
the peer QNE to resend the entire QSPEC stack, would the recover still be
necessary?

Sven>> The idea underlying the suggestion is to limit the signalling delay
while still notifying upstream peers of a potential problem. It is
therefore intended for the period before (any of) the upstream QNEs react
to the notification by e.g. resending the stack. If the recovery turns out
to be wrong, resending the stack will solve it the next time around. If it
was correct, the signalling delay is minimised.

> 2. How far can a QNE inspect the QSPEC stack?
>       a. only the next QSPEC
>       b. the entire stack
> This is essentially a trade-off between the amount and type
> of errors that you want to recover from and the complexity.
> Suggestion is to allow inspection of the entire stack in case
> the edge QNE is the same for several layers.

Maybe this also depends on whether the recover is possible based on the
next
QSPEC. If the recover isn't possible, i.e. whole stack of QSPEC needs to be
resent, there is no need to go any furhter.

Sven>> I'll try to give an example:

+-----+        QSpecC            +-----+      +-----+
| QNE1|------------------------->|     |      |     |
+-----+                          |     |      |     |
                                 |     |      |     |
          +-----+    QSpecB      |     |      |     |
          | QNE2|--------------->| QNE4|----->| QNE5|
          +-----+                |     |      |     |
                                 |     |      |     |
                    +-----+QSpecA|     |      |     |
                    | QNE3|----->|     |      |     |
                    +-----+      |     |      |     |
                                 +-----+      +-----+

Suppose QNE4 is the edge of the domains in which QSpecs A, B and C are
valid. The stack looks like QSpecA (top)-QSpecB-QSpecC. QNE5 only knows
QSpecC. Suppose for some reason QNE4 does not terminate domains A and B,
then QNE5 can recover from the error by inspecting the stack 2 deep (until
it finds QSpecC). The correct behaviour is then to discard everything
above. This means that it might be useful to go deeper into the stack.

> 3. What should be done with the stack when a deeper QSPEC is
> recognised
>       a. leave intact
>       b. discard all QSPECs above the recognised QSPEC
> Suggestion: discard everything above. This avoids that all
> subsequent QNEs need to do the same inspection.

This is closely related to the point 2. Does this assume that there is no
more unrecognized QSPEC between the "deeper QSPEC" and the end of the
stack?

Sven>> No, in the example above QSpecB (unrecognised) is between QSpecA
(unrecognised) and QSPecC (recognised).

Cheers

Cheng Hong

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

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 25 Feb 2004 16:15:30 +0800

Hi Sven,

Please see a few further comments inline:

> <snip>
> > 1. Should a QNE attempt to recover from an unrecognised QSPEC stack 
> > ...
> Does this also depend on what the error message contains and 
> how the QNE peer responds to the error message? If the error 
> message would simply cause the peer QNE to resend the entire 
> QSPEC stack, would the recover still be necessary?
> 
> Sven>> The idea underlying the suggestion is to limit the signalling 
> Sven>> delay
> while still notifying upstream peers of a potential problem. 
> It is therefore intended for the period before (any of) the 
> upstream QNEs react to the notification by e.g. resending the 
> stack. If the recovery turns out to be wrong, resending the 
> stack will solve it the next time around. If it was correct, 
> the signalling delay is minimised.

So in this case, the QNE must be able to reconginize the certain QSPEC has
already been processed upon receiving the retransmitted QSPEC stack. The RSN
could be used, but it means different QoS Model would have to maintain its
own record of the current sequence number.

> of errors 
> > that you want to recover from and the complexity. Suggestion is to 
> > allow inspection of the entire stack in case the edge QNE 
> is the same 
> > for several layers.
> 
> Maybe this also depends on whether the recover is possible 
> based on the next QSPEC. If the recover isn't possible, i.e. 
> whole stack of QSPEC needs to be resent, there is no need to 
> go any furhter.
> 
> Suppose QNE4 is the edge of the domains in which QSpecs A, B 
> and C are valid. The stack looks like QSpecA 
> (top)-QSpecB-QSpecC. QNE5 only knows QSpecC. Suppose for some 
> reason QNE4 does not terminate domains A and B, then QNE5 can 
> recover from the error by inspecting the stack 2 deep (until 
> it finds QSpecC). The correct behaviour is then to discard 
> everything above. This means that it might be useful to go 
> deeper into the stack.

Yes. I agree that in this case, the QNE should inspect the whole stack until
it found one recognized Qspec. 

> This is closely related to the point 2. Does this assume that 
> there is no more unrecognized QSPEC between the "deeper 
> QSPEC" and the end of the stack?
> 

My question is if there is any possibility that an Qspec D (unrecognized)
could be appear after QSpecC (recongnized)? E.g. QSpecA
(unrecognized)-QspecB (unrecognized)-QspecC (recognized)-QspecD
(unrecognized)

Cheers

Cheng Hong