Subject: [NSIS] QoS NSLP: More open issues

From: Roland Bless <[email-masked]>
Date: Tue, 10 Jan 2006 23:54:41 +0100

Hi all,

we have some more issues on
http://www.cs.helsinki.fi/u/jmanner/diff-qosnslp-08-09.html

* NOTIFY:
  still unsolved
  - usefulness of NOTIFY after state tear down
  - forwarding scope of NOTIFY
  for details please see prior mail from Markus Ott:
  http://www.ietf.org/mail-archive/web/nsis/current/msg05784.html

* section 4.8 Rerouting:
   After the reservation on the new path is set up, the branching node
   or the merging node may want to tear down the reservation on the old
   path (faster than what would result from normal soft-state time-out).

  It is unclear to me why and how the merging node should tear down the
  reservation on the old path: Only a reserve can carry a TEAR flag
  and it can only be sent towards the QNR. Furthermore, the branching
  node will usually detect the rerouting earlier anyway, because GIST
  will indicate a changed SII-handle via a network notification.

  in the same context:
* section 5.4.1:
   NSLP state. If the SII is different, this means that the QNE is a
   merge point. In that case, in addition to the operations specified
   above, the value REPLACE=0 is also indicating that a tearing RESERVE
   SHOULD NOT be sent on the old branch.

  As above: the merge point cannot initiate a tearing RESERVE.
  Furthermore, in case the QSPEC and MRI are not changed, the merging
  QNE need not send the RESERVE further downstream because the state
  along the remaining path has not changed.

* section 4.8 Rerouting:

   A QNI or a branch node may wish to keep the reservation on the old
   branch.  This could for instance be the case when a mobile node has
   experienced a mobility event and wishes to keep reservation to its
   old attachment point in case it moves back there.  In that case, it
   sets the REPLACE flag in the common header to zero. Note that keeping
   old reservations affects the resources available to other nodes.
   Thus, the operator of the access network must make the final decision
   on whether this behavior is allowed. Also, the QNEs in the access
   network may add this flag even if the mobile node has not used the
   flag initially.

  It is not clear for how long the reservation should be kept, i.e.
  how long should the branching node keep sending refreshes? Should
  it do so at all?

* section 5.4.3. RESPONSE Messages:
  forwarding of RESPONSES with RIIs:

  In case of a successful answer (class 0x02) forwarding should stop
  at the node that inserted the RII object, however in case
  of errors forwarding should possibly not stop at the RII inserting
  node, because other nodes upstream are possibly also interested in
  failures. Unclear is whether informational messages should be handled
  like success. Furthermore, some protocol errors are only meaningful
  between directly adjacent peers.

  Currently the paragraph reads:

   On receipt of a RESPONSE message containing an RII object, the
   statefull QoS-NSLP 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 QNE did not insert this RII itself, if must forward the RESPONSE
   to the next peer. Thus, forwarding should only stop if the QNE
   inserted the RII by itself.

  Should possibly be rephrased in:
   On receipt of a RESPONSE message containing an RII object, the
   stateful QoS-NSLP 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
   it contains an INFO_SPEC class informational or success. If
   the QNE did not insert this RII itself, if must forward the RESPONSE
   to the next peer. Thus, for RESPONSES indicating success, forwarding
   should only stop if the QNE inserted the RII by itself, If the
   RESPONSE carries an INFO_SPEC indicating an error, forwarding SHOULD
   continue upstream towards the QNI by using RSNs as described in the
   next paragraph.

* section 7.1

   "Note that we assume the SII handling in GIST [I-D.ietf-nsis-ntlp]
    is extended to distinguish between own and peer SII."

   This is not necessary, so you should delete this sentence.

  SendMessage(...) (Fig. 35) and RecvMessage(...) (Fig. 36) should have
  the same parameters as in the GIST draft.

Typos:
* section 4.8, p.31:
   receiver-initiated reservations, this involves A QNE that is notified
                                                  ^a
* section 5.1.3.6., p. 45:
   If a QNE encounters protocol erros, it MAY include additional
                                ^^^^^
                                errors

   If the type of an object is erroneous, the following optional error-
   spefici information may be included at the end of the INFO_SPEC.
   ^^^^^^^
   specific

Please comment,
 Roland

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

---

From: Jian Zhang <[email-masked]>
Date: Wed, 11 Jan 2006 15:22:00 +0000 (WET)

Hi, Roland,

See my comments inline. I also report two more open issue below.

* section 5.1.2.1 RESERVE:
   REPLACE (R) - when set, indicates that a RESERVE with different
   Message Routing Information (MRI) replaces an existing one, so the
   old one MAY be torn down immediately.  This is the default
   situation.  This flag may be unset to indicate a desire from an
   upstream node to keep an existing reservation on an old branch in
   place.

This flag is also used to indicate that whether the reserved resources 
on the old branch should be teared down or not when the data path change 
happens (see, section 4.6 Rerouting). In this case, the MRI is the same 
and only the route path is changed. So, this feature should also be 
included in the above description text of REPLACE flag.

* section 5.1.3.5 PACKET_CLASSIFIER:
   The flags indicate which fields from the MRI should be used by the
    packet classifier. Flags MUST only be set if the data is present in
    the MRI (i.e. if there is a flag for it in GIST, then that must also
    be set).

In my understanding, which flags will be set in PACKET_CLASSIFIER 
should be directed by the QOS Model used becuase these flags is to 
indicate which fields from the MRI will be used by the packet
classifier to classfy the incoming packets of this flow. Therefore, the 
QoS Model function should be mentioned at the above description of 
PACKET_CLASSIFIER and this part "(i.e. if there is a flag for it in GIST, 
then that must also be set)" should be removed due to it makes no sense 
(or even is wrong).

Also, because the PACKET_CLASSIFIER is to indicate to the packet 
classifier at each QNE that which fields from the MRI will be used to
classify the incoming packets of one flow, the PACKET_CLASSIFIER object 
is only needed for the RESERVE message. Only the RESERVE message will 
reserve the resources for the flow at the QNEs along the flow's data 
path and only after the reservation, the packets of the flow could be 
accepted into the network. Thus, including the PACKET_CLASSIFIER object in 
the QUERY, RESPONSE and NOTIFY messages make no sense (see 
sections 5.1.2.2, 5.1.2.3 and 5.1.2.4 where the QUERY, RESPONSE and 
NOTIFY messages also include the PACKET_CLASSIFIER object).

>  http://www.ietf.org/mail-archive/web/nsis/current/msg05784.html

Agree with you.

>  will indicate a changed SII-handle via a network notification.

The reason why the merging node may need to tear down the reservation on 
the old path explicitly is because that this explicit tear down is faster 
than the implicit tear down via the soft-state time-out. Can the 
merging node initiate a tearing RESERVE message to the old branching 
node? I think the first merging node can, see the example below.

     QNI------ QNE2 ----------QNE3--------QNE4-------QNE5-----QNR
                |                          |
                |                          |
                |-------------QNE3'--------|

    Previously, flow 1 took the path QNI-QN2-QNE3-QNE4-QNE5-QNR, and after
    some time, its path changes to QNI-QNE2-QNE3'-QNE4-QNE5-QNR. The QNE2
    and QNE4 are called the merging nodes here. Due to this is the
    case of sender-initiated reservation, now the path change is detected
    when QNE2 receives a RESPONSE message with a different SII from QNE3'.
    Then, the merging node QNE2 is aware of the path change and can
    initiate a tearing RESERVE message with TEAR flag set and send it to
    QNE3 to tear down the resources reserved for this flow at QNE3. QNE3
    can further propagate this tearing RESERVE message to QNE4. But, the
    question is that how long this tearing message should be propagated.

    In my opinion, the merging node QNE4 must not stop propagating this
    tearing RESERVE message if it is already aware that it is the latter
    merging node of this path change, i.e., it is aware that its
    upstream peer is changed but the downstream peer is not. Meanwhile,
    the new RESERVE message sent by QNE2 to QNE3' should also be stop
    prapogating by QNE4. In this way, all those QNEs which are at the same
    path as before do not need to tear down the resources and then reserve
    the same resources again and again for the same flow.

>  along the remaining path has not changed.
See above.

>  how long should the branching node keep sending refreshes? Should
That may depend on the local policy.

>   continue upstream towards the QNI by using RSNs as described in the
Agree with you. Especially when the RESPONSE message is to indicate that 
the previous RESERVE action failed due to some severe errors (such as the 
authentication failure or no enough resources), the RESPONSE should be 
forwarded to the QNI, which then can initiate a tearing RESERVE message to 
inform those QNEs which have already reserved resources to release them.

>  the same parameters as in the GIST draft.

Agree. Now the APIs illustrated in Fig. 35 and Fig. 36 are inconsistent 
with the ones defined in GIST. The editors should discuss and fix this 
problem.

Regards,

Jian Zhang

---

From: Roland Bless <[email-masked]>
Date: Thu, 12 Jan 2006 13:51:54 +0100

Hi Jian

> included in the above description text of REPLACE flag.

Agreed.

> In my understanding, which flags will be set in PACKET_CLASSIFIER should
> be directed by the QOS Model used becuase these flags is to indicate
> which fields from the MRI will be used by the packet
> PACKET_CLASSIFIER and this part "(i.e. if there is a flag for it in
> GIST, then that must also be set)" should be removed due to it makes no
> sense (or even is wrong).

I guess you're right that the sentence in parentheses is wrong.
Actually problably wanted to say something like:
(i.e. it is only allowed to set if there is a flag for it in GIST).

> accepted into the network. Thus, including the PACKET_CLASSIFIER object
> in the QUERY, RESPONSE and NOTIFY messages make no sense (see sections
> 5.1.2.2, 5.1.2.3 and 5.1.2.4 where the QUERY, RESPONSE and NOTIFY
> messages also include the PACKET_CLASSIFIER object).

Hmm, sounds logical to me. Maybe someone who thinks that
this is necessary could speak up now, otherwise we should
remove the PACKET_CLASSIFIER from all PDUs except the RESERVE.

> the old path explicitly is because that this explicit tear down is
> faster than the implicit tear down via the soft-state time-out. Can the

The draft states it already, but it mentiones

> node? I think the first merging node can, see the example below.

I guess we have a terminology problem here, because I differentiate
between branching and merging nodes (as the draft does sometimes).
See below.

>    and QNE4 are called the merging nodes here. Due to this is the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This would be quite confusing. If the data is flowing from QNI to QNR
I would call QNE2 the branching node (flows split) and QNE4 the merging
node (flows join again). The following is correct if you simply
s/merging/branching.

>    question is that how long this tearing message should be propagated.

Usually, QNE4 will detect that it is a merging node and has another
active reservation for the same SID _and_ the same flow. Tear down
the old reservation should stop at QNE4 in this case. But if the flows
(i.e. MRIs) are different, it must propagate the RESERVE w/ TEAR further
along the path.

>    upstream peer is changed but the downstream peer is not. Meanwhile,

That's basically what I mean by merging node.

>    the same resources again and again for the same flow.

I don't understand your proposal. You say QNE4 should propagate the
TEAR further downstream, but the new RESERVE should stop at QNE4?
This would lead to a reservation along the new path that stops at QNE4.

I guess we should better distinguish at least these cases:
- Rerouting occurred without change of flowID (MRI).
  In this case QNE2 (as branching node) will detect
  the route change and initiate a new RESERVE with RII set.
  This new RESERVE will stop at the merging node
  who sends a RESPONSE w/ RII back. In case of success
  QNE2 will see that the new path was successfully established
  and starts to TEAR down the reservation along the old branch.
  This TEAR will nevertheless stop at QNE4 in order to prevent
  tearing down the reservation along the unchanged path.
- The flowID changed. We assume that the old flow and the new
  flow will share some parts of their paths, i.e. both flows
  traverse a common set of nodes. In this case, QNE4 should
  neither stop propagating the new RESERVE nor stop to forward
  the tearing reserve.
- FlowID stays the same, but QSPEC has changed. In this case
  QNE4 should forward the new RESERVE, but not the RESERVE w/ TEAR.

>>  along the remaining path has not changed.

The above sentence says that QNE4 is not able to tear down
the old branch (only QNE2 may do so).

> That may depend on the local policy.

Sure, however. one must implement something...
I would then suggest to add something like:
How long an old reservation is kept depends on local policy.

> the previous RESERVE action failed due to some severe errors (such as
> the authentication failure or no enough resources), the RESPONSE should
> be forwarded to the QNI, which then can initiate a tearing RESERVE
> message to inform those QNEs which have already reserved resources to
> release them.

But even if upstream nodes only sent regular refreshing RESERVEs
it may be necessary. Consider a rerouting event like in the above
scenario. In case the new RESERVE along the new branch fails due to
resource shortage, upstream nodes should be notified of this failure.
In this case they will get "unsolicited" RESPONSEs (which match the
RSN of the refreshing RESERVE).

> with the ones defined in GIST. The editors should discuss and fix this

Seems to be fixed now.

Regards,
 Roland

---

From: Jian Zhang <[email-masked]>
Date: Thu, 12 Jan 2006 15:03:47 +0000

Hi, Roland,

See comments below.

> (i.e. it is only allowed to set if there is a flag for it in GIST).

The sentense in the parentheses probably wanted to say something like you
mentioned above. But I think it is also redundant because the MRI is sent by
the QoS-NSLP to GIST and then QoS-NSLP can check the consistency between the
PACKET_CLASSIFIER and MRI at the QoS-NSLP level and need not bother the GIST. 

> remove the PACKET_CLASSIFIER from all PDUs except the RESERVE.

Agree.

> >    and QNE4 are called the merging nodes here. Due to this is the

Ok with me if the QNE2 is called the branching node and the QNE4 the mergering
node. In this case, I agree with you that only the branching node should and
can initiate the tearing RESERVE message to tear down the reservation on
the old path.

> TEAR further downstream, but the new RESERVE should stop at QNE4?

No. What I proposed is that the QNE4 should stop propagating both the tearing
RESERVE from QNE3 and the new RESERVE from QNE3' when the MRI remains the same.
For the case that the MRI has changed and the old flow and the new
flow shares some parts of their pathes, the merging node QNE4 should propagate
both the tearing RESERVE from QNE3 and the new RESERVE from QNE3'. 
 
>   QNE4 should forward the new RESERVE, but not the RESERVE w/ TEAR.

Agree.

> the old branch (only QNE2 may do so).

Yes, only QNE2 can initiate the tearing RESERVE message to tear down the
reservations on the old path. If we agree to call the QNE2 the branching node
and the QNE4 the merging node, then some descriptions about rerouting in the
draft have to be updated/changed.
 
> How long an old reservation is kept depends on local policy.

Agree.

> RSN of the refreshing RESERVE).

I agree with you. What I tried to say above is that, on receipt of a RESPONSE
message containing an RII object and carring an INFO_SPEC indicating an error,
whether this RESPONSE message will be forwarded further until the QNI should
depend on the error code and subcode contained in the INFO_SPEC. If the error
code and subcode indicate some severe errors (e.g., the authentication failure
or resource shortage, etc), then this RESPONSE should be forwared further until
the QNI even one QNE matches the RII successfully.

Regards,

Jian