Subject: [NSIS] QoS NSLP (draft-12) NOTIFY for reduced refreshes

From: Roland Bless <[email-masked]>
Date: Thu, 26 Oct 2006 15:38:55 +0200

Hi,

though now the ACK flag is gone, there is still this very questionable
mechanism: namely sending back a NOTIFY to indicate support for reduced
refreshes. Maybe someone can enlighten me with the rationale for this.
I don't get the point. IMHO if reduced refreshes are not supported,
the QNE will respond with an error message "Full QSPEC required"
anyway, so an explicit positive acknowledgment using NOTIFY is
NOT NECESSARY. Furthermore, there is not really any good guidance
what happens when this NOTIFY is missing (->what timeout?). Sec 5.4.1
says only that if the NOTIFY is missing one must use full refresh
messages, but usually one could infer that from getting the
corresponding error message (Transient 0x04). I even don't get
the point why it would make sense then to keep setting the
Q-bit in subsequent requests???

Pleeeaaase provide a little more rationale for this feature!
Otherwise I propose to delete that feature (sending NOTIFY back
if Q-bit is set), because we have a corresponding error message
for this case.

Regards,
 Roland

P.S.: this was still on my list because no one answered this
IIRC:
http://www1.ietf.org/mail-archive/web/nsis/current/msg06128.html

--------------------------------------------------------
 Now the relevant sections from draft-12:

5.4.4.  NOTIFY Messages
   A special case of synchronous NOTIFY is when the upstream QNE asked
   to use reduced refresh by setting the appropriate flag in the
   RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY
   and a proper INFO_SPEC code whether the QNE agrees to use reduced
   refresh between the upstream QNE.

3.2.5.  Reduced Refreshes
   ....

   These reduced
   refreshes require an explicit acknowledgment to ensure that the RSN
   reference will be understood. It is up to a QNE that receives a
   message containing an special flag bit to decide whether it wants to
   accept reduced refreshes and provide this explicit acknowledgment. It
   sends a NOTIFY message as answer to the received RESERVE.

5.4.1.
   If a QNE has not received a NOTIFY confirming the use of reduced
   refreshes from its downstream peer for a session, the QNE MUST
   continue to use full refresh messages. It MAY add the Q-bit (Request
   Reduced Refrehses) in subsequent refresh messages in order to
   continue asking the downstream QNE to use reduced refrehes.
----------------------------------------------------------------------

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

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 26 Oct 2006 17:48:02 +0300 (EEST)

Hi Roland,

If we expect that reduced refreshes would be the default way to refresh 
reservations, then we could formulate the spec as you say. Thus, a QNE 
would indicate with the Q-bit that it is going to use the default reduced 
refreshes, and the upstream QNE should only send a NOTIFY back if it 
doesn't support the reduced operation.

Jukka

---

From: Roland Bless <[email-masked]>
Date: Thu, 26 Oct 2006 17:34:59 +0200

Hi Jukka,

> reservations, then we could formulate the spec as you say. Thus, a QNE 

I always saw it like this: reduced refreshes are mandatory to support.
If, for some reason, e.g. hitting a new node, a reduced refresh cannot
be supported by a QNE it will simply send back this error message
"full QSPEC required" and the upstream QNE must repeat the RESERVE
with QSPEC. If this error occurs repeatedly with a node (why should
that be the case? Avoiding to store the QSPEC?) for a session
the QNE should keep sending full QSPECs instead of reduced ones
(maybe someone could give a rationale/example for why reduced refreshes
cannot be supported by a node in principle).

> refreshes, and the upstream QNE should only send a NOTIFY back if it 

I guess that Q-bit/NOTIFY stuff is intended be a somewhat "hidden
negotiation" of a reduced refresh feature. However, I don't
need a Q-bit to notice that the sender sent a reduced refresh.
A QNE automatically determines that because the QSPEC is missing.

> doesn't support the reduced operation.

No, no, no. Don't send a NOTIFY back, simply send the
error "full QSPEC required" back. Everything we need is
already there! Why this strange NOTIFY?
I only could imagine some more specific subtype for the
full QSPEC required error:
- full QSPEC required due to new session establishment
- full QSPEC required because reduced refresh not supported
(and as said above: what is the scenario for the latter error?)

Regards,
 Roland

---

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 26 Oct 2006 20:06:42 +0300 (EEST)

Hi,

I basically follow your logic. Perhaps Andy or Georgios can comment why a 
reduced refresh would not be understood?

About sending back a NOTIFY: that is how errors are sent. ;) A NOTIFY can 
include and INFO_SPEC telling about "Full QSPEC required", you can't send 
back an INFO_SPEC without a message header. :)

Jukka

---

From: Roland Bless <[email-masked]>
Date: Fri, 27 Oct 2006 09:23:06 +0200

Hi Jukka,

> reduced refresh would not be understood?

Good.

> back an INFO_SPEC without a message header. :)

And I thought it must be a RESPONSE with an INFO_SPEC. That would be
the more natural way to indicate an error (NOTIFY is usually
asynchronous whereas failed RESERVES or QUERIES should generate
a RESPONSE containing an error description in the INFO_SPEC).

Regards,
 Roland