Subject: [NSIS] Further open QoS NSLP issues

From: Roland Bless <[email-masked]>
Date: Thu, 06 Oct 2005 16:54:34 +0200

Hi,

[I'm not really sure whether anyone is tracking my QoS NSLP
issues at all here on this list...e.g.,
http://www1.ietf.org/mail-archive/web/nsis/current/msg05345.html
http://www1.ietf.org/mail-archive/web/nsis/current/msg05359.html
I got zero responses from the authors so far to the above message]

While we are implementing things I have several
additional comments for the QoS NSLP:

* Wouldn't it make sense to forward 4xx/5xx RESPONSEs
  along the path upstream towards QNI even if no RII was
  originally included in the RESERVE?

*  Sec. 5.4.3 says
   "The RESPONSE message is
   impotent, it does not cause any state to be installed or modified."

   I don't think that the above statement is correct:
   a) in case of a failure (the RESPONSE carries code >=300) a QNE
      will usually release any already allocated resources which
      is deletion of state. Is this not seen as modification?
   b) in case a RESPONSE indicates that there are less resources
      available downstream than requested by the RESERVE, a QNE
      may/should free some resources which is a state modification.

* It is not possible to send back an error for a QUERY w/o RII.
  In this case one could only detect that there is no corresponding
  RESERVE after a while and retransmit. This should be documented.

* NOTIFY should also not alter any state. However, in case a notify
  signals a fatal error condition, state deletion may be a correct
  action (at least the state machine draft proposed this. If wrongly
  then we need clarification in the QoS NSLP draft).

* How should a node behave if it gets a RESPONSE with a non-matching
  RSN?

  Drop it silently? If so, then please add a clear statement in
  sec. 5.4.3.
  Currently, you could not send back an error message, because
  NOTIFY is defined as asynchronous message.

* Sec. 4.1
  "Any node may include a request for a RESPONSE in its RESERVE
  messages.  It does so by including a Request Identification
  Information (RII) object in the RESERVE message."

  One could clarify in sec. 4.1 and/or 5.3.2 that if an RII object is
  already included in a message, an interested QNE must not add an
  RII object, but may simply remember that RII to match the related
  RESPONSE it is interested in later. When it receives the RESPONSE,
  it forwards the RESPONSE upstream towards the RII originating node.

* Sec. 5.2.1 says:
   "List of RII for outstanding responses with processing information the
   RII is a 32 bit number."

   Conceptually we have two RII lists in 5.2.1:
   Own RIIs (this QNE inserted originally the RII), Foreign RIIs (other
   nodes inserted the RII upstream, but the QNE is interested in the
   RESPONSE, too).

* This would also help to clarify Sec. 5.4.3:
  "On receipt of a RESPONSE message containing an RII object, the QNE
   MUST attempt to match it to the outstanding response requests for
   that signalling session.  If the match succeeds, then the RESPONSE
   MUST NOT be forwarded further along the path."

  This is only true in case the RII is found in the list of Own RIIs.

* RII conflict Error Msg
  It is said that the RII should be unique within a session and
  different for each message. However, I could imagine a scenario
  when a QNI sends a RESERVE message with a specific RII and some
  QNE also initiates a RESERVE with the same RII value for the same
  session simultaneously. The QNE may trigger this RESERVE in order
  to reserve resources along a new branch due of a route change.
  Ok, the probability may be really small, but one should be prepared
  for such things...
  So due to some event, a QNE will receive a message with an RII that is
  already in use. In this case it might be good to let the QNE send an
  error message back stating that there is an RII conflict, i.e. it is
  already in use.

* Who sends a response to the RESERVE with RII, sometimes it may
  be the QNR sometimes it may be a cross-over QNE, i.e. the RESERVE
  (e.g. carrying a TEAR) may not always be propagated all along the
  whole path to the far end, it may stop earlier at a cross-over
  node. IMHO this should be clarified in the text.

Best regards,
 Roland

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 6 Oct 2005 19:24:37 +0300 (EEST)

Hi Roland,

I'll try to answer some of your comments below. Sorry to have missed your
feedback.

Jukka

>   originally included in the RESERVE?

[JM]: We are in the middle of reworking out how/when/why errors are sent.  
In order to protect from DoS attacks, a QNE should consider twice before
sending error messages upstream or downstream.

>       is deletion of state. Is this not seen as modification?

[JM]: Good point.

>       may/should free some resources which is a state modification.

[JM]: So you mean that QNEs that already made the reservation should free 
those reservations? In general, yes, but a QoS model might have other 
rules?

>   RESERVE after a while and retransmit. This should be documented.

[JM]: I'm still discussing the use of QUERY messages with my co-authors. 
I would see that all queries must have an RII. But then, how do simple 
queries differ from ones intended to trigger a receiver-initiated 
reservation... that is what I wonder mylsef...

>   then we need clarification in the QoS NSLP draft).

[JM]: I guess this depends on the QoS model?

>   NOTIFY is defined as asynchronous message.

[JM]: Dropping a "wierd" message would be the default action. This has 
been added to my editor's copy for the forthcoming draft.

>   it forwards the RESPONSE upstream towards the RII originating node.

[JM]: Good point. yet, there may emerge collisions with RIIs "shared" 
between QNEs. Should we actually support some kind of stacked RIIs? Same 
as we do for QSPECs already?

>    nodes inserted the RII upstream, but the QNE is interested in the

[JM]: Sounds right.

>   This is only true in case the RII is found in the list of Own RIIs.

[JM]: Yes, good clarification.

>   error message back stating that there is an RII conflict, i.e. it is

[JM]: Need to think about this some more...

>   node. IMHO this should be clarified in the text.

[JM]: Will do.

---

From: Roland Bless <[email-masked]>
Date: Thu, 06 Oct 2005 20:46:03 +0200

Hi Jukka,

> I'll try to answer some of your comments below. Sorry to have missed your

Thanks for the quick response.

> sending error messages upstream or downstream.

Hmm. I'm not really sure about DoS attacks in this respect.
With GIST and TLS below I don't see such a big risk. However,
you're right: its always good to follow Jon Postel principle
"Be liberal in what you accept, and conservative in what you send."
On the other hand: in case the RESERVE carried an RII object,
the QNE simply would send and forward such RESPONSES.

> [JM]: So you mean that QNEs that already made the reservation should free 

I had [min,max] reservations in mind..
Simple example: RESERVE requests at minimum 150kbit/s up to 500kbit/s
bandwidth. Let's assume 500kbit/s are pre-allocated in this QNE, but a
returning RESPONSE signals that only 300kbit/s could be reserved
downstream along the path. If the QNE sees the response, it would
usually free 200kbit/s which may be used by other reservations then.
However, it actually depends on the policy of the QoS model.

> those reservations? In general, yes, but a QoS model might have other 

Yes, but then this should be stated in this way: the specific action is
up to the QoS model. But I would suggest to give an example what may
happen. Currently, the draft description limits what a QoS model can do.

> reservation... that is what I wonder mylsef...

If QUERY has always an RII, IMHO the alternatives would be:
a) a new message type (code)
b) a flag in the common header

Hmm, as you might know, I made a different suggestion for
receiver-initiated reservations and mentioned to Andrew
at the last meeting that the RESERVE-RI could also be sent
hop by hop in some kind of bypassing mode instead of directly
end-to-end. Actually, that's how we implemented it in our MARSP
signaling protocol, because it has advantages with respect to
signaling relationships and security. So the proposal is as follows:
The receiver sends this RESERVE-RI to its next GIST hop towards
the flow sender. Every GIST node / QNE would simply forward
this RESERVE-RI. There is, however, no
need to install any state (in the QoS NSLP), it's more like bypassing
the node. If the RESERVE-RI arrives at the flow sender, it simply
initiates a RESERVE (this is the analog to the receiver-initiated
RESERVE triggered by the special QUERY) containing a BOUND_SESSION_ID,
referring to the RESERVE-RI session. The receiver will handle the
RESERVE as RESPONSE to its RESERVE-RI due to the matching BOUND_SESSION_ID.

I see two advantages:
a) RESERVE is always sender-initiated, which may simplify some things.
b) The receiver doesn't have to worry about whether reverse path
   state was already installed before.

> [JM]: I guess this depends on the QoS model?

Yes, but then we should state that rather than stating that
it has no effect at all. Like in the above case, an illustrating
example what may happen would be also good here.

> been added to my editor's copy for the forthcoming draft.

Good. However, I think it's worth to mention this case explicitly.

> as we do for QSPECs already?

No, I don't think it would be a good idea to stack RIIs.
In the rare case of collisions, the QNI could immediately retry
with another RII if we have an explicit 0x04 error for this.

> [JM]: Need to think about this some more...

Mainly it specifies an action in case we have an RII conflict,
which may be a rare event, but it may happen from time to time.
I suggest to send a transient failure back, so the QNI can
retry with another RII.

Regards,
 Roland

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 7 Oct 2005 09:48:32 +0200

Hi Roland and Jukka

Below you can see my comments to your suggestions!

----- Original Message ----- 
From: "Roland Bless" <[email-masked]>
To: "Jukka MJ Manner" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Thursday, October 06, 2005 8:46 PM
Subject: [NSIS] Re: Further open QoS NSLP issues

-//- snip

> happen. Currently, the draft description limits what a QoS model can do.

[Georgios]: Agree, we will state that!

> b) a flag in the common header

[Georgios]: I think that a flag in the common header will solve this 
problem!

>   state was already installed before.

[Georgios]: I think that your proposal can also be solved by a QUERY message 
in combination with a special
QoS model!

> example what may happen would be also good here.

[Georgios]: Agree on this!

> Good. However, I think it's worth to mention this case explicitly.

[Georgios]: Agree

>>>   it forwards the RESPONSE upstream towards the RII originating node.

[Georgios]: Here I agree with Roland on this! We have to clarify it in the 
text!

> with another RII if we have an explicit 0x04 error for this.

[Georgios]: I agree that it is not a good idea to stack RIIs

> I suggest to send a transient failure back, so the QNI can

[Georgios]: This is a good point!

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Mon, 17 Oct 2005 10:28:25 +0200

Hi Jukka,

>>I got zero responses from the authors so far to the above message]

There were also other QoS NSLP issues in the cited messages.
Could you please check them? Thanks,
 Roland