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

From: [email-masked]
Date: Thu, 26 Feb 2004 14:09:39 +0100

Hi Robert, Andrew, all,

I am starting to feel a lot for Andrew's proposed solution. However, I am
wondering if the correct answer might depend on the mode used by GIMPS,
i.e.
- connection mode: reasonable to assume you know which models are supported
by your peer
- datagram: not so reasonable to make this assumption

I would say that in connection mode, you just send an error message back
and let the sender solve the problem (i.e. become the edge of the domain if
necessary). The solution seems to be either resend in datagram mode (hence
tunneling through the offending (Q)NE) or to terminate and look deeper.

In datagram mode, maybe you should just pass on the message as is and
behave like an NE?

Sven

"Hancock, Robert" <[email-masked]> on 26/02/2004 10:56:25

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

cornelia,

my mental model of operation is to consider that
- nodes where reservations are installed understand the
  QoS models that they accept reservations for (this is
  obvious)
- nodes which request reservations of other nodes must
  be able to request it in language that those 'other'
  (neighbour) nodes understand (not quite so obvious
  but reasonable IMHO)

in that case, the bit in your scenario where it goes

> So the RESERVE proceeds through a multitude of
> domains. Now one domain somewhere does not recognize the QoS
> model in the bottom QSpec.

is a should-not-happen error condition (i.e. I think this
is an assumption we should make):
- the previous domain understood and installed the
  reservation in its own nodes
- it knows it is connected to a neighbour domain
- it knows (or should find out as a matter of urgency) if
  that neighbour doesn't support a QoS-model that it itself
  does (whether that is the only model on the stack or just
  the topmost one doesn't really matter)
- in that case, it should be able to translate its own
  understanding of the requested QoS (it must have an
  understanding, since it installed the reservation...)
  into language that the neighbour does understand.

some details: i assumed that re-writing was allowed only
in so far as the qos model specified it (qos models might
allow re-writing of some fields but not others, for example).
I assumed that arbitrary re-writing is not possible (unless
you terminate the signalling session at a node and start
a new one) - that is what the stacking is for, to make
such things unnecessary.

on the gracefull fallback case: this is worth thinking about.
conceptually it is not much different from passing through
an NSIS-unaware node (and we certainly have to be capable of
that!)

cheers,

robert h.

> -----Original Message-----
> From: Kappler Cornelia [mailto:[email-masked]]
> Sent: Thursday, February 26, 2004 09:37
> To: McDonald, Andrew; Kappler Cornelia;
> [email-masked]';
> Cheng Hong
> Cc: [email-masked]; 'Georgios Karagiannis'
> Subject: AW: [NSIS] QoS NSLP open issue on error cases with QSPEC
> stacking
>
>
> Hi Andrew,
>
> I also agree putting too much "intelligence" into QNEs (i.e.
> assumptions on what went wrong and hence how it is to be
> fixed) may result in hard-to-understand system behaviour and
> backfire (i.e. not speed up processing).
>
> On the other hand, imagine a QNI trying to set up a
> reservation with an unknown QNR many domains away (e.g.
> reserving IP telephony resources between Europe and the
> Solomon Islands). Of course the QNI doesnt know what QoS
> model the QNR understands. So it will pick a "well known" QoS
> model for the first QSpec, and then may be stack a local QoS
> model on top. At the border of QNIs domain, the local QSpec
> will be popped, and possibly, depending on SLAs between
> domains, the bottom QSpec will be rewritten (is this allowed
> by qos-nslp?). So the RESERVE proceeds through a multitude of
> domains. Now one domain somewhere does not recognize the QoS
> model in the bottom QSpec. Do we really want to stop the
> RESERVE until this domain and the originating domain came up
> with a solution? May be a "graceful fallback" would be to
> send an error message, and continue to forward the RESERVE
> and put up with one domain on the path not reserving
> resources. This is similar to how RSVP works I believe.
>
> This raises the question of whether we should have a "default
> QoS model" that must be understood by everybody (a can of
> worms, I know, so probably not)?
>
> How would the "graceful fallback" be realized? Popping a
> QSpec when there is no other left is no good (another reason
> why the original idea needs amendment). So may be the QNE who
> does not understand the topmost QSpec tags it. The next QNE
> would again try and interpret the topmost object. If it
> succeeds, apparently (assumption!) the QNE before was
> _within_ the QoS model domain but malconfigured. The RESERVE
> proceeds with the tag which tells the QNE popping the topmost
> QSpec one (or at least one - depending on how many bits we
> spend on this) QNE was unable to reserve resources. May be
> because we already sent the error message, the tag is
> redundant and not necessary. Of course this procedure doesnt
> help in the case of a QNE not popping a QSpec it was supposed
> to pop. In this case we produce processing overhead because
> all QNEs up to the QNR try to interpret a QSpec they are
> unable to interprete, and the reservation fails anyways.
>
> Thinking aloud (and hoping such issues have not yet been
> discussed at length on this list...), Cornelia
>
>
> > -----Ursprüngliche Nachricht-----
> > Von: McDonald, Andrew [mailto:[email-masked]]
> > Gesendet: Mittwoch, 25. Februar 2004 18:15
> > An: 'Kappler Cornelia'; [email-masked]'; Cheng Hong
> > Cc: [email-masked]; 'Georgios Karagiannis'
> > Betreff: RE: [NSIS] QoS NSLP open issue on error cases with
> > QSPEC stacking
> >
> >
> > 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).
> >
> >
> > --
> > 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.
> >
>
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
>

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

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 26 Feb 2004 14:30:30 +0100

Hi Sven, Andrew, Robert

I also agree with the conclusion derived by Andrew.  The sending node has to
be
informed about the error. Since the sending node has the required
information
on making such a decission, and other nodes may not, let the responsibility
for recovering to the sending node.

Note, however that there are different ways on how the sending node can be
informed
about this error. These ways could depend on the used NTLP mode.

Best Regards,
Georgios

----- Original Message ----- 
From: <[email-masked]>
To: "Hancock, Robert" <[email-masked]>
Cc: "'Kappler Cornelia'" <[email-masked]>; "McDonald, Andrew"
<[email-masked]>; "Cheng Hong" <[email-masked]>;
<[email-masked]>; "'Georgios Karagiannis'" <[email-masked]>
Sent: Thursday, February 26, 2004 2:09 PM
Subject: RE: [NSIS] QoS NSLP open issue on error cases with QSPEC stacking