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

[Cedric Westphal <[e-mail]>]

Gabor,

thanks for your comments.

Gabor Fodor wrote:

>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.
>
Hemant has first hand knowledge of these requirements.

>
>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. 
>
The draft will probably evolve as the requirements and framework do.

>
>
>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. 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.
>
One of our goal was to state that a 'one size fits all' solution cannot 
solve all the requirements
in these drafts. There are then two approaches: one is to weed out 
requirements until it's
solvable with one protocol. To us, it would bring a compromised solution 
as contradictory
requirements are necessary in the different scenarios that the signaling 
encounters during the
lifetime of a flow. The other approach is what we wanted to underline: 
that some existing tools might be combined into a signaling toolkit that 
would meet the requirements.
To answer your point: we should definitely write up an analysis on how 
our proposal answers the requirements you mention. We will do it as we 
enter design phase.

>
>
>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 assymmetric
>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.
>
Ok.

>
>
>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 ?
>
We do not discuss much QoS initiation, as we assume that some 'general 
signaling' such as RSVP establishes the QoS in the first place. So the 
negotation is really what you name QoS adaptation signaling. We should 
add some emphasis to this.

>
>
>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.
>
Let me explain a bit here: the design base for edge signaling and 
context transfer is
really 'A context transfer protocol for seamless mobility', 
draft-koodli-seamoby-ctv6-03.txt.
Earlier version of draft-koodli-seamoby-ctv6 were ICMP based. However, 
it is more general in this latest version, and not necessarily ICMP. As 
a consequence, we mention ICMP
as a possible illustration. The main point is that QoS signaling is 
redundant with context transfer, one object being transferred being QoS 
context, and that CT signaling will do the job for the MN to AR QoS 
signaling.
We will clarify this point.


>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.)
>
The architecture of rfc2998 is that of heterogeneous nodes on the path, 
some controlling the resource, and some forwarding traffic. This is 
inside the network, and orthogonal in a way to the edge signaling. What 
we meant by citing rfc2998 was that we were dealing with
'in-band signaling so a subset of the routers on the path'.

>
>
>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. 
>
Good point; Hemant might correct me, but I don't think we discussed it?

>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.
>
Will do.
Thanks for the comments,


Cedric.

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