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

From: Gabor Fodor <[email-masked]>
Date: Fri, 28 Jun 2002 16:19:32 +0200 (MET DST)

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. 

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.

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.

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 ?

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.

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

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. 

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.

> From: Cedric Westphal <[email-masked]>
> To: [email-masked]
> CC: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis

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

---

From: Cedric Westphal <[email-masked]>
Date: Fri, 28 Jun 2002 15:33:14 -0700

Gabor,

thanks for your comments.

>important input and can evolve to a good design base.
Hemant has first hand knowledge of these requirements.

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

>specifically on the edge signaling.
Ok.

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

>we start discussing what existing or new protocol can be the
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.

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

>may not be necessary) or not. 
Good point; Hemant might correct me, but I don't think we discussed it?

>the whole model around the figure in Section 1, but this
Will do.
Thanks for the comments,

Cedric.