Subject: [NSIS] Some QoS NSLP draft-07 issues

From: Roland Bless <[email-masked]>
Date: Fri, 19 Aug 2005 01:56:14 +0200

Hi,

I have some questions/remarks which may need clarification:

p. 21, sec 4.3:
   QNE.  The same processing is performed at further QNEs along the
   path, up to the receiver, which in this situation is the QNR.  The
   QNR detects that this QUERY message does not carry an RII object and

shouldn't this read twice _QNI_ instead of QNR (this is at least what
the figure says)? If not then the text should be clarified (i.e. you
mean QNR for the QUERY?).

sec. 5.2.1:
  SII for each upstream and downstream peer

      The SII is a large identifier (minimum 128 bits) generated by the
      QoS NSLP and passed over the API.

This seems to be not consistent with the GIST spec:
As far as I understood, the SII is managed by the GIST implementation
and passed over the API so for the above text s/NSLP/NTLP. Furthermore,
here is requirement for its length >128bits which cannot be found in
the GIST spec?

p. 43, sec. 5.3.2:
  When sending a message containing an RII object the sending node MUST
  remember the value used in the RII to match back any RESPONSE
  received.  It SHOULD use a timer to identify situations where it has
  taken too long to receive the expected RESPONSE.  If the timer
  expires without receiving a RESPONSE it MAY perform a retransmission.

the text needs clarification. IMHO only the QNI should start a
retransmission. As the text currently reads every QNE may also
perform a retransmission.
Furthermore:
should a node generate an error message if
 - RII timeout went off and no RESPONSE came back
 - a RESPONSE came in too late, i.e. RII timeout?
   How should this response be handled (ignore,
   forward or dropp)?
IMHO no error message should be generated and the QNI
should retransmit the original message two times with
increasing backoff.

sec. 5.4.1: There is currently no text specifying how RESERVE with RII
            must be processed in QNEs, e.g. nodes could take advantage
            of interpreting returned RESPONSES indicating failure,
            so that QNEs can tear down state in case the initial

            reservation failed downstream.

sec. 5.4.3: that's the same issue that Tseno already mentioned:
            how should a RESPONSE ever get forwarded to the QNI
            if we follow:

   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.  If the match fails,

            that makes no sense to me...

Questions over questions...

Regards,
 Roland

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