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

From: "McDonald, Andrew" <[email-masked]>
Date: Wed, 25 Feb 2004 17:14:57 -0000

Hi all,

Some further ruminations.

Looking at this in a different way, and going back to the fundamentals: is what is being sent a "stack of QSpecs", or a "choice of QSpecs"?

I think we're talking about a "stack":
The source QNE is requesting the resources in the top object. So, actually processing a different object is wrong (we would be reserving something different to what we were asked for). Then, since it is the source QNE who asked for that QSpec (and sent it with the expectation of it being honoured), the responsiblity for fixing the problem should be pushed back to it.

It is an error case anyway, so correctness should be the goal, rather than making it fast/seamless. It is desirable to limit the error propagation - if you know you have got bad data (a QSpec for an unsupported qos model), you should limit how far this gets propagated. Either 'fixing' the set of QSpecs at the receiving QNE, or forwarding them unchanged would result in the error affecting the resources requested at subsequent nodes.

If you were to go with the "choice" view, then the source QNE would be asking for any one of the QSpecs in the set to be processed. However, you still need to handle the case where none of the QSpecs can be understood. Allowing the receiving QNE to choose also means that the RESERVE does not have a deterministic result from the sending QNEs point of view - it doesn't know which QSpec will be used.

My conclusion would be that the receiving node should not attempt any recovery (looking deeper into the set of QSpecs and maybe subsequently stripping off QSpecs). Instead it should just send an error back and leave the responsibility for recovering to the sending QNE.

How does that argument sound?

Andrew

McDonald, Andrew wrote:
> I suppose, in a way we are asking: 'how are people going to get their
> network configuration wrong?', which is rather a difficult one to
> answer.  
> 
> If the problem is that 'edge' nodes don't undo QSpec stacking, then
> you might want the node receiving the unknown QSpec to become the
> edge (look deeper, and strip). You probably also want to send back
> error messages, asking the previous node to become the edge (don't
> send me a QSpec for that qos model again).    
> 
> If problem is 'non-edge' nodes that don't understand QoS models they
> should, then you want things to carry on as if that node wasn't there
> (possibly look deeper, but don't strip). In this case, sending errors
> back might also be the wrong answer (if it tells previous nodes not
> to send something they should be sending).    

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

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 26 Feb 2004 13:12:40 +0800

Hi Andrew,

Generally I agree that the recover at the QNE could be risky, and seems not
that helpful for the system. Please see some comments inline.

Cheers 

Cheng Hong

> -----Original Message-----
> From: McDonald, Andrew [mailto:[email-masked]] 
> Sent: Thursday, February 26, 2004 1:15 AM
> To: 'Kappler Cornelia'; [email-masked]'; Cheng Hong
> Cc: [email-masked]; 'Georgios Karagiannis'
> Subject: RE: [NSIS] QoS NSLP open issue on error cases with 
> QSPEC stacking
> 
> 
> Hi all,
> 
> Looking at this in a different way, and going back to the 
> fundamentals: is what is being sent a "stack of QSpecs", or a 
> "choice of QSpecs"?
> 
> The source QNE is requesting the resources in the top object. 
> So, actually processing a different object is wrong (we would 
> be reserving something different to what we were asked for). 
> Then, since it is the source QNE who asked for that QSpec 
> (and sent it with the expectation of it being honoured), the 
> responsiblity for fixing the problem should be pushed back to it.
> 
> It is an error case anyway, so correctness should be the 
> goal, rather than making it fast/seamless. It is desirable to 
> limit the error propagation - if you know you have got bad 
> data (a QSpec for an unsupported qos model), you should limit 
> how far this gets propagated. Either 'fixing' the set of 
> QSpecs at the receiving QNE, or forwarding them unchanged 
> would result in the error affecting the resources requested 
> at subsequent nodes.

Agree. Based on this reasoning, recover at the QNE may result in unstable
system.

> If you were to go with the "choice" view, then the source QNE 
> would be asking for any one of the QSpecs in the set to be 
> processed. However, you still need to handle the case where 
> none of the QSpecs can be understood. Allowing the receiving 
> QNE to choose also means that the RESERVE does not have a 
> deterministic result from the sending QNEs point of view - it 
> doesn't know which QSpec will be used.

In this case, the QNE should always send ACK (RESPONSE) for the RESERVE,
which could inform the peer QNE of the Qspec being accepted. It sounds like
a kind of negotiation mechanism.

Is there any use case that may require such kind of use of the Qspec in
RESERVE?

> My conclusion would be that the receiving node should not 
> attempt any recovery (looking deeper into the set of QSpecs 
> and maybe subsequently stripping off QSpecs). Instead it 
> should just send an error back and leave the responsibility 
> for recovering to the sending QNE.
> 
> > you might want the node receiving the unknown QSpec to 
> become the edge 
> > (look deeper, and strip). You probably also want to send back error 
> > messages, asking the previous node to become the edge (don't
> -- 
> Registered Office: Roke Manor Research Ltd, Siemens House, 
> Oldbury, Bracknell, Berkshire. RG12 8FZ
> 
> The information contained in this e-mail and any attachments 
> is confidential to Roke Manor Research Ltd and must not be 
> passed to any third party without permission. This 
> communication is for information only and shall not create or 
> change any contractual relationship.
> 
> 
>