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

From: [email-masked]
Date: Tue, 17 Feb 2004 11:41:15 +0100

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

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
- 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

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?

Best regards,
Sven Van den Bosch

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

---

From: "Cheng Hong" <[email-masked]>
Date: Wed, 18 Feb 2004 12:22:47 +0800

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:

[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. 

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.

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.

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.

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.

[/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]

> - 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, 

[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.

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.

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.

[/CH]

---

From: "Yuming Wang" <[email-masked]>
Date: Thu, 19 Feb 2004 16:52:56 +0800

Hi Cheng Hong,

Some more considerations:
In your RZR solution for the ping-pong type of movement, admission
control should be carried out when the old path is re-established
using a modification RESERVE message. If there is not enough
resource on the old path, access of the MN will be denied. so, how
to do admission control is another issue.

>preservation, reservation could be just torn down according to local policy.

Cheers,
Yuming
2004-02-19
---------------- Yuming Wang -----------------
NGIT Research Group, ITEC R&D Center, EI Dpt.,
HuaZhong University of Science and Technology.
Email:     [email-masked]
Home Page: http://itec.hust.edu.cn/wym.htm
TEL: +86-27-87453207  FAX: +86-27-87456436
----

---

From: "Cheng Hong" <[email-masked]>
Date: Thu, 19 Feb 2004 17:02:22 +0800

Hi Yuming,

Thanks for the comments.

I think the admission control is always a separate problem. If the old path
could not provide the resources for re-establishment, the RESERVE will fail.
This is common regardless of whether RZR solution is used. To use the RZR
solution would allow you to know that the old path could not suppor the
session faster. (since it get rid of the signaling association setup
process) It is not to guarantee that MN could be supported when it moves
back, which is the job of resource management module, and is out of scope of
the draft.

Cheers

Cheng Hong

> From: Yuming Wang [mailto:[email-masked]] 
> Sent: Thursday, February 19, 2004 4:53 PM
> To: Cheng Hong
> Cc: nsis
> Subject: Re: [NSIS] FW: discussion on 
> draft-cheng-mobility-issues-01.txt impact on QoS NSLP
> 
> 
> Hi Cheng Hong,
> 
> In your RZR solution for the ping-pong type of movement, 
> admission control should be carried out when the old path is 
> re-established using a modification RESERVE message. If there 
> is not enough resource on the old path, access of the MN will 
> be denied. so, how to do admission control is another issue.
> 
> >Hi Sven,
> >
> the issues 
> >> you raise are:
> >> 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
> >[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.
> >
> >"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.
> >
> >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.
> >
> >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.
> >
> >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.
> >
> >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.
> >
> >[/CH]
> >
> >[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]
> >
> >
> >> - 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:
> >> 
> 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
> >> 
> >[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.
> >
> >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.
> >
> >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.
> >
> >[/CH]
> >
> >> Best regards,
> >> Sven Van den Bosch
> >> 
> >> 
> >> 
> >
> >
> >
> >
> >

---

From: "Yuming Wang" <[email-masked]>
Date: Thu, 19 Feb 2004 17:43:25 +0800

Hi Cheng Hong,

I'm really appreciated for you answer.
Thank you!

>.

Yuming
2004-02-19