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

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 25 Feb 2004 10:53:19 -0000

Hi all,

[I've replied to this message in the thread, since I got confused about some points later on in the discussion....]

Cheng Hong wrote:
> 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?

I think that the error message says "you've sent me a qos model I don't understand. i've recovered from it by looking deeper." or "you've sent me a qos model I don't understand. i've given up.". The node receiving this should not repeat the RESERVE with the same qos model (resending the same QSpec stack doesn't appear to help in any way). It might resend a different QSpec stack (e.g. without the top one, or use some different qos model entirely).

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

There is also option z (which comes before 'a'), which is that you only look at the top QSpec and never try to recover by looking deeper.

I'm not sure what you mean by "whole stack of QSPEC needs to be resent", since this about attempting recovering without requiring anything to be resent.

(I see later in the thread you've replied to Sven's example and think option (b) is ok).

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

Yes, this does follow on from (2), but I don't see how your second sentence is relevant.

To give an example. A sequence of three QNEs in this part of the path:
.... <---> A <---> B <---> C <---> ....

A sends B a RESERVE containing {QSpec2,QSpec1} (for qos model 2, and qos model 1). QSpec2 is the 'top' of the stack. B doesn't understand qos model 2. Going with the 'look deeper' solution, it looks at QSpec1.

Now, what should B send to C?
option (a) is {QSpec2,QSpec1}
option (b) is {QSpec1}

regards,
Andrew

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

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 25 Feb 2004 19:13:46 +0800

Hi Andrew,

<snip>
> 
> I think that the error message says "you've sent me a qos 
> model I don't understand. i've recovered from it by looking 
> deeper." or "you've sent me a qos model I don't understand. 
> i've given up.". The node receiving this should not repeat 
> the RESERVE with the same qos model (resending the same QSpec 
> stack doesn't appear to help in any way). It might resend a 
> different QSpec stack (e.g. without the top one, or use some 
> different qos model entirely).

If the peer QNE decides to send a different Qspec, it may means that the QNE
should not do any recover. The resent does not need to be the exact Qspec
stack. It could only contains the "correct" stack.

I agree with Sven that the recover can help in saving some time for the QNE
instead of waiting for the peer QNE to reply. But this does not seem to be a
very compelling reason.

<snip>
> 
> There is also option z (which comes before 'a'), which is 
> that you only look at the top QSpec and never try to recover 
> by looking deeper.
> 
> I'm not sure what you mean by "whole stack of QSPEC needs to 
> be resent", since this about attempting recovering without 
> requiring anything to be resent.

That is the point I raised above. If the "error" triggers the resent, there
may be no need to do recover.

Also, how would the peer QNE know if this QNE could recover from the error
message? It might still need to recontruct a correct RESERV message, and
resent.

> and think option (b) is ok).

In the case drawn out by Sven, it seems that option (b) is OK.

> > 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?
> 
> To give an example. A sequence of three QNEs in this part of 
> the path: .... <---> A <---> B <---> C <---> ....
> 
> A sends B a RESERVE containing {QSpec2,QSpec1} (for qos model 
> 2, and qos model 1). QSpec2 is the 'top' of the stack. B 
> doesn't understand qos model 2. Going with the 'look deeper' 
> solution, it looks at QSpec1.
> 

Suppose the stack looks like (QSpec2, Qspec1, Qspec 0)
According to (b), it would be (QSpec1, QSpec0). The question is "is there
any chance that QSpec0" is also unrecongnized?

Best regards

Cheng Hong