Subject: [NSIS] Re: FW: discussion on draft-cheng-mobility-issues-01.txt impact on QoS NSLP

From: [email-masked]
Date: Fri, 20 Feb 2004 10:20:45 +0100

Hi Cheng Hong,

Thanks for your replies. Please see my comments inline.

Best regards,
Sven

"Cheng Hong" <[email-masked]> on 18/02/2004 05:22:47

To:    Sven VAN DEN BOSCH/BE/ALCATEL@ALCATEL
cc:    <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject:    FW: discussion on draft-cheng-mobility-issues-01.txt impact on
       QoS NSLP

Hi Sven,

Thanks a lot for reviewing the draft. Please see some response to the
questions inline:

Best regards

Cheng Hong

PS: A copy of the draft is available at link below:
http://www.psl.com.sg/draft-cheng-mobility-issues-01.txt

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, February 17, 2004 6:41 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: discussion on draft-cheng-mobility-issues-01.txt
> impact on QoS NSLP
>
>
> Hi,
>
> I have gone through your draft. If I understand correctly,
> the issues you raise are:
> - the need for the QoS NSLP to support a change of FlowID for
> the same sessionID (e.g. multi-homing)
> - the need to deal intelligently with very frequent
> (ping-pong) mobility events

[CH]: That is correct.
[/CH]

> I agree with the need for both types of functionality, but I
> don't think the impact on QoS NSLP is very large. From what
> you propose in the draft, the current version of the QoS NSLP
> (draft-ietf-nsis-qos-nslp-02.txt)
> supports:
> - ability to reserve zero resources

[CH]: I have browsed through the qos-nslp-02 draft. Seems there were quite
some details added.

As for the RZR proposed, it is different from the normal zero reservation
using the QSPEC. It is more like another version of the TEAR. Here below
are
some of the reasons that the RZR is needed in the qos-nslp.

1) The RZR is for a QoS NSLP layer CRN to put states over old path to
"dormant" mode. It is not simply set corresponding QSPEC to zero. E.g. it
could indicate the QNE for other special treatment, gradual reduce of
resource, etc. The action to be taken at each node is as you mentioned a
policy issue. Using the normal QSPEC to set to resource to zero could not
achieve this.

Sven>> I still don't understand why. If you want to gradually reduce
resources for instance. this can be achieved by refreshing on the old path
with decrementing resource requirements. The indication of what you call
'special treatment' is always possible. We have for instance QoS-model
specific control information that can be used for that.

2) Using the zero QSPEC would cause the QNE lost information about the old
state. It is not good for the restore process. A RZR option instead could
allow QNE retain the original state information, even the QSPEC.

Sven>> What the CRN QNE could do is send a RESERVE with zero resources and
keep the QSpec locally in order to be used once the resources on the old
path become needed again. Wouldn't this achieve the same purpose?

3) The tear down RESERV message may not carry QSPEC object. In this case,
an
RZR option, similar to the TEAR, would be more suitable than an extra QSPEC
that puts burden on the network.

Sven>> Could you clarfiy this point?

4) To use the current QSPEC to indicate the RZR requires each QoS model to
generate a QSPEC with zero resources involved. It could be heavy for the
QNE.

Sven>> I don't think it will be heavier than RZR since you don't need to
put anything in the QSpec (zero resources)

Besides above, I feel that the lacking part in the current qos-nslp draft
is
how the RZR is used. Supposedly, the RZR should replace the TEAR RESERV
message to be sent from an QoS NSLP layer CRN. Since a CRN could be any
QNE,
this behavior should be defined in the QoS NSLP. Also, how the
corresponding
QNE response to the RZR should be explained.

Other than that, how the return to the old path is recognized, and how to
restore and reuse the state over the old path could be incorporated into
the
qos-nslp draft as well.

Sven>> I agree we could better explain how RESERVE with zero resources can
be used to address the points that you raise.

[/CH]

> - ability to retain/remove state on the old path: supported
> in QoS NSLP (with SII) but the decision to keep state is a
> policy issue at the QNE, not indicated by MN

[CH] Although the QNE could decide how to deal with the old state, it still
needs information from other nodes to make the decision. For example, how
would the QNE know the MN is doing multi-homing with the indication from
the
MN? Of course, the QNE could decide how to react at this indication
according to its local policy.
[/CH]

> What you propose that is currently not there:
> - MN indication of desire to maintain old path state. We
> could do this via a flag in the header which is minimal
> impact but I am concerned about:
>
> 1. security: can be solved by making support optional and
> leave the QNE the freedom to disregard it 2. relation to
> charging, ...: if it is just an indication, not mandatory,
> who will be charged for maintaining the reservation
>
> Have you thought about these issues?

[CH] You are correct that a flag could achieve the purpose at most of the
time. But, as we briefly described in the draft that in certain case, the
Flow-ID is needed, and a flag is necessary for each of the FLOW-ID.

Sven>> I don't follow you completely here. Do you mean that a single
RESERVE message of a multi-homed host needs to contain more than one
flowID? Or would you send different RESERVEs for each flowID and know that
they can share resources on common paths because they belong to the same
sessionID?

As for the security, the indication (flag) would be bundled with the RESERV
(or the corresponding RESPONSE) of the new path. It should maintain the
same
security level as the RESERV message. In case the MN is not the QNE, the
communication would be between MN and a NSIS proxy, which would be out of
scope of the draft.

Since this option is to be indicated in the reservation process over the
new
path, the QoS NSLP layer CRN has already been discovered (at least RESERV
could indicate that), some cookies could used for enhancing the security of
the message. For example, if the RESERV is send from CRN to MN, the CRN
could include a cookie in the RESERV, and MN can make use the cookie to
secure its RESPONSE or NOTIFY to the CRN that indicates it's desire.

Sven>> OK, if it is the expression of a 'desire' the security risks are
less. I was worried you wanted to mandate the CRN to honour the MN's
desire.

As for the charging, the MN should be charged for maintaining the
reservation, since it's requested by the MN. (could be a special service
subscription option? Or QoS level?) If the MN does not indicate the
preservation, reservation could be just torn down according to local
policy.

Sven>> If it is a specific QoS level, we don't need it in the QoS NSLP. QoS
models are described in other drafts. Is the conclusion of this discussion
that:
- we propose to the WG to foresee a flag that allows QNEs to indicate that
they want resources on old paths be kept and refreshed
- better explain how RESERVE with zero resources may be used to support
this

Would this address your issues?

Best regards,
Sven

[/CH]

> Best regards,
> Sven Van den Bosch

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

---

From: "Cheng Hong" <[email-masked]>
Date: Fri, 20 Feb 2004 17:59:06 +0800

Hi Sven,

Thanks a lot for your detail comment. I think my feeling is that the RESERV
with a zero QSPEC could achieve the purpose if the behavior of the QNE for
processing this type of RESERV message is well defined. But, this may put
some limit for the future extension, and therefore, it maybe better to make
it a separate object/option by analogy to the introduction of the TEAR flag.

Please see some furhter comments inline.

<snip>
> 
> 1) The RZR is for a QoS NSLP layer CRN to put states over old 
> path to "dormant" mode. It is not simply set corresponding 
> QSPEC to zero. E.g. it could indicate the QNE for other 
> special treatment, gradual reduce of resource, etc. The 
> action to be taken at each node is as you mentioned a policy 
> issue. Using the normal QSPEC to set to resource to zero 
> could not achieve this.
> 
> resources for instance. this can be achieved by refreshing on 
> the old path with decrementing resource requirements. The 
> indication of what you call 'special treatment' is always 
> possible. We have for instance QoS-model specific control 
> information that can be used for that.

[CH] 
The point I tried to make is that if the zero QSPEC is used to achieve this
purpose, the QNE must be configured to interpret it in a specific way.
Therefore, it is not that flexible. And make the RZR a separate object would
allow more information to be included.
[/CH]

> 2) Using the zero QSPEC would cause the QNE lost information 
> about the old state. It is not good for the restore process. 
> A RZR option instead could allow QNE retain the original 
> state information, even the QSPEC.
> 
> Sven>> What the CRN QNE could do is send a RESERVE with zero 
> resources 
> Sven>> and
> keep the QSpec locally in order to be used once the resources 
> on the old path become needed again. Wouldn't this achieve 
> the same purpose?

[CH] 
Yes. It can achieve the goal. But, CRN would need to update all the QNE of
the QSPEC when restoring the old path.
[/CH]

> 3) The tear down RESERV message may not carry QSPEC object. 
> In this case, an RZR option, similar to the TEAR, would be 
> more suitable than an extra QSPEC that puts burden on the network.
> 

[CH]
I am assuming that the QSPEC used to set the resource to zero would still
have all the fields included, just with all the parameters set to zero.
Therefore, it takes more bits to indicate the same meaning than a RZR flag
(or something similar). Of course, if the zero QSPEC you meant is something
special, e.g. a simple header field, etc, it may be similar to the proposed
RZR object.
[/CH]

> 4) To use the current QSPEC to indicate the RZR requires each 
> QoS model to generate a QSPEC with zero resources involved. 
> It could be heavy for the QNE.
> 

[CH]
Similar to the point above. Also, I am assuming that the QSPEC is generated
by the individual QoS models. So, it would be most costy to generate than a
generic QoS NSLP layer RZR flag/object.
[/CH]

> Besides above, I feel that the lacking part in the current 
> qos-nslp draft is how the RZR is used. Supposedly, the RZR 
> should replace the TEAR RESERV message to be sent from an QoS 
> NSLP layer CRN. Since a CRN could be any QNE, this behavior 
> should be defined in the QoS NSLP. Also, how the 
> corresponding QNE response to the RZR should be explained.
> 
> Other than that, how the return to the old path is 
> recognized, and how to restore and reuse the state over the 
> old path could be incorporated into the qos-nslp draft as well.
> 
> Sven>> I agree we could better explain how RESERVE with zero 
> resources 
> Sven>> can

[CH]
This could also be a way to solve the problem. My concern is just that it
may not be that extensible.
[/CH]

<Snip>
> 
> [CH] You are correct that a flag could achieve the purpose at 
> most of the time. But, as we briefly described in the draft 
> that in certain case, the Flow-ID is needed, and a flag is 
> necessary for each of the FLOW-ID.
> 
> RESERVE message of a multi-homed host needs to contain more 
> than one flowID? Or would you send different RESERVEs for 
> each flowID and know that they can share resources on common 
> paths because they belong to the same sessionID?

[CH]
I think the point is that if there are multiple flows associated with the
same session, this indication object should contain the specifc flow id to
be tear down, so that other flows would not be affected. The indication
object is just an attachment to the RESERVE message, and would not affect
the normal content of the RESERV message.
[/CH]

<snip>
> 
> Sven>> If it is a specific QoS level, we don't need it in the 
> QoS NSLP. 

[CH]
Sorry for causing the confusion. What I meant is that about the charging, it
could linked to the subcription of the user. If the user request to keep the
old path, he would be charge according to certain SLA he signed.
[/CH]

> Sven>> QoS
> - we propose to the WG to foresee a flag that allows QNEs to 
> indicate that they want resources on old paths be kept and refreshed

[CH] Yes. We agree to forward with this. 
[/CH]

> - better explain how RESERVE with zero resources may be used 
> to support this

[CH] 
Please see my comments above. 
[/CH]

Cheers

Cheng Hong