[NSIS] RE: Comments on draft-westphal-nsis-qos-mobileip-00.txt

[[e-mail]]

Hi Gabor:

Thanks for the comments. Please see inline: 

-----Original Message-----
From: ext Gabor Fodor [mailto:[e-mail]]
Sent: Friday, June 28, 2002 10:20 AM
To: Weshphal Cedric (IPRG/MtView); Chaskar Hemant (NRC/Boston)
Cc: [e-mail]
Subject: Comments on draft-westphal-nsis-qos-mobileip-00.txt


Hi Cedric and Hemant,

I understand from the mail discussions and especially from the
interim meeting, that the WG is encouraged to take into 
consideration the requirements formulated in : 

http://www.ietf.org/internet-drafts/
draft-ietf-mobileip-qos-requirements-02.txt

From that perspective, I think that your draft is an
important input and can evolve to a good design base.
However, I also understand that the group is
in the process of discussing the requirements and the framework
drafts, so I am not sure whether starting discussing this
draft is appropriate right now.

[Hemant] Yes, NSIS is indeed in requirements and framework phase. Please note that the MIP QoS solution in our draft has good compatibility with current NSIS framework document. Some highlights are: in-band signaling, use of optimized solution modules for different parts of network (horizontal signaling and vertical signaling with respect to handoff) as well as specific items for MIP mentioned in the framework document. So, I think that it might be worthwhile to have some discussion (at least on mailing list) on this draft to create some kind of design base for MIP QoS signaling, as you have said above. Such discussion can also provide feedback to framework document.    

Anyway, here comes a set of comments from my perspective.

Best regards /Gabor

---------------------------------------------------------------
1
I agree that we need to consider a QoS signaling that works
in a mobile/wireless environment and that the wireless bandwidth
economy must be an important factor. From this point of view,
I would like to see a more clear discussion on the requirements
that this draft provides the solution for. 

[Hemant] The main air interface bandwidth saving procedures that we have contemplated in the draft are: use of context transfer signaling between ARs to avoid sending much of the information over the air as well as avoiding (as much as possible) any traversals of wireless links (on both MN and CN side) during vertical signaling procedures.

Clearly, we have 
at least two important input documents: the NSIS requirement
doc and the mobileip-qos-requirements doc. I think that your 
framework draft should try to identify which of these requirements
it considers important and which new ones it adds to those.

[Hemant] In this draft, we have considered following requirements as prime ones: air interface bandwidth saving, fast QoS establishment after handoff,   authentication of handoff-induced signaling (to avoid spoofing attacks) and minimizing the impact of signaling on the segment of packet path that remains unchanged after handoff.

2
I also agree that we need to differentiate between the "edge" 
signaling, the context transfer signaling and the 
"data path signaling". We need to be careful with statements
like "lightweight signaling mechanism required over the
wireless link". We indeed want to minimize both 
the number and the length of signaling messages over the air
(so in that sense it should be lightweight), but we do
want to provide enough information to efficiently configure
wireless resources, often per user flow and per-flow
state maintenance with support of bi-directional asymmetric
reservation, etc.
I think that the draft should define what is meant by "wireless
bandwidth economy" and discuss more the requirements 
specifically on the edge signaling.

[Hemant] As you can see, for now, the critical mass of the draft is on vertical signaling. We have briefly described horizontal signaling, mainly to show its relation to vertical signaling. This has been done with the hope that we can borrow context transfer work from Seamoby to the extent possible for the edge QoS signaling part.   

3
The draft talks about the negotiation procedures (in 4.2).
In my opinion the draft should identify the requirement more
clearly, preferably with a reference to either the NSIS or
the mobile IP requirement draft. Is there a difference between
negotiation (which takes place upon QoS initiation time) and 
QoS adaptation signaling which may take place upon hand-over ?

[Hemant] We have advocated one pass reservation approach in the interest of speed of QoS establishment (in other words, minimize the number of packets that may get default forwarding treatment after handoff, just because QoS signaling has not yet completed). In most of the handoff cases, the request will be granted. But, there could be cases when requested QoS < offered QoS, and then, MN may choose to have control over decision as to whether to continue or terminate the session. For this case, we have provided fallback mechanism in the form of negotiation procedure. If the MN knows at handoff time (e.g. handoff from 2.5G to WLAN or vice versa) as to whether it needs to adapt QoS after handover to the characteristics of new access, it will put the adapted QoS parameters in the QoS signaling packet in the first place. Even after that, if some router cannot offer the requested QoS, we have negotiation procedure as fallback.  

4
I am not sure that it is meaningful at this point to start
discussing specific solution approaches. You seem to propose
to use ICMP as a design base for both edge signaling and for
context transfer (AR to AR). At least for the edge signaling,
we need to consider the edge specific requirements before
we start discussing what existing or new protocol can be the
design base for that.

[Hemant] Continuing my earlier comment about reusing as much from Seamoby for edge signaling, ICMP has been proposed in anticipation that  context transfer protocol in Seamoby will be ICMP based. It is precisely for the reason you mention above, that we have refrained from specifying any specific protocol to carry vertical signaling. Rather, we have focused on the characteristics that such carrier protocol, the information it may convey, processing of that information at intermediate nodes and security of signaling. 

5
You mention RFC2998 as one of your basic references, which I 
think is a very useful RFC in this context as well. 
However, from 
the draft it is not clear how you use that in the proposed
architecture. (Since ICMP seems to be the base and not RSVP.)

[Hemant] RFC2998 has following conceptual elements in it: signaling follows data path (which now is also in NSIS charter statement) and a set of routers on end to end path (QCs) control the QoS. We also started with this architecture. From this point onward, RFC2998 goes on to specify how RSVP can signal QoS over this architecture, while we choose a different signaling method.

6
You identify QoS release as a necessary functionality.
Here there is a need to identify if the protocol should
support soft state (in which case this explicit QoS release
may not be necessary) or not. 

[Hemant] In soft state approach, explicit TEAR DOWN may not be required. Of course, if inter-REFRESH period is chosen long enough to save REFRESH signaling overhead, TEAR DOWN can still help. Finally, if we go for soft state & no tear down approach, the TEAR DOWN part of the protocol can be gracefully omitted.

7
As a minor detail issue,
I see some problems with the definition of the cross-over router.
I believe that your definition in 4.1.3 would identify 
several routers as cross-over router, whereas later on
it seems that only the first merging point is really used
as cross-over router. By the way, the notion of cross-over
router in my opinion should be introduced when you present
the whole model around the figure in Section 1, but this
is a presentation issue.

[Hemant] Thanks for the comments, and apologies if some of above points were not clear from the write-up.

Hemant



> From: Cedric Westphal <[e-mail]>
> To: [e-mail]
> CC: [e-mail]
> Content-Transfer-Encoding: 7bit
> Content-Transfer-Encoding: 7bit
> Subject: [NSIS] QoS framework.
> Hi all,
> 
> we put together a document representing our perspective on a
> NSIS qos signaling framework.
> 
> Here is the abstract:
> 
> Abstract
> 
>    This draft provides a framework for QoS signaling that is optimized
>    for Mobile IP handoffs. It covers the horizontal signaling between
>    access routers (ARs) as well as the vertical signaling along the
>    packet data path, both of which are triggered by handoff of mobile
>    node (MN). The key design goals are wireless bandwidth economy,
>    fast QoS establishment along the new data path after handoff and
>    secure protocol operation.
> 
> 
> The document will eventually be available from the i-d editor queue. However,
> only after Yokohama meeting. You can find it at:
> http://people.nokia.net/~cedric/Papers/draft-westphal-nsis-qos-mobileip-00.txt
> in the meantime.
> Please send your comments,
> 
> Cedric & Hemant.
> 
> 
> 
> 
> _______________________________________________
> nsis mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/nsis


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