Subject: Re: [mobile-ip] QoS Work Item

From: "Hemant Chaskar" <[email-masked]>
Date: Thu, 29 Mar 2001 22:20:18

Hi,
It will be a good idea to use some premises while discussing this issue 
(please feel free to add to this list):

1. We should concentrate on QoS _signaling_ protocol that a  _host _ would 
use to signal the QoS requirement of its flows along the new end-to-end 
path. Please note the distinction between the

QoS protocols as used by network domains/routers for purposes such as QoS 
management, admission control, setting up LSPs or Label switched paths, 
MPLS-TE, Diffserv SLAs etc.

and

the QoS _signaling_ protocol used by _host_.
As long as the QoS _signaling_ protocol can deliver sufficient (possible 
more) information to the network/router level QoS modules, it interoperates 
with the QoS modules in the end-to-end path. It should not matter if this 
flow-level information (QoS requirement, traffic volume, packet 
classification parameters etc.) is delivered to the router by QoS signaling 
protocol X or Y.

2. QoS signaling protocol must work with heterogeneous QoS schemes: IntServ, 
DiffServ or MPLS. MN may switch between IntServ and DiffServ access domains 
due to handovers. Also, handover may cause the path in the core network 
(which may be using MPLS) to change as well (consider handover between 
indoor LAN and cellular network).

3. We need to consider _fast_ QoS signaling along the new end-to-end path 
after handover. It is not acceptable that the QoS signaling scheme takes one 
round trip time (as in RSVP) before QoS contexts are set up in the 
intermediate nodes after handover. Note that handover may occur in the 
middle of running QoS-sensitive session such as VoIP session.

4. We need to discuss what is more important from mobility perspective. Few 
examples are as follows:

- QoS signaling protocol such as RSVP has been optimized with central focus 
on multicast. However, Mobile IP is not used if MN is receiving multicast 
session. In other words, in multicast case there are no binding messages, MN 
uses IGMP to register at the new AR.

- Should QoS signaling protocol be designed with central focus on topology 
changes or frequent handoffs.

- Pure static policy based QoS may not work in mobile environment. For 
example, MN may land up in the visited domain during a session where its 
flow parameters are not compliant with the QoS policy parameters in that 
domain. For example, the policy in the visited network may be to use port 
number x for an EF call and y for best effort if you are accessing Internet 
from that domain. However, MN already using port y for VoIP session may land 
up in this visited domain.

Prioritizing these issues from mobility perspective will be important as 
single QoS _signaling_ protocol may not satisfy all the requirements.

5. Interoperability and optimization with micro-mobility solutions. Here, we 
should also think if we need to provide QoS _signaling_ solution at IP layer 
or transport layer. Micro-mobility information is most readily available at 
IP layer. A secondary issue that arises here is whether CoA information 
should be accessible anywhere above IP layer. Because if transport layer 
protocol can grab this information, any other application can also do so 
thereby causing privacy concerns.

6. We need thin protocol as it may not be desirable to add another protocol 
software on sleek mobile terminals.

7. Issues like security, scalability are important as they always have been.

8. What other working groups may find this item within their scope? 
Definitely not MPLS, DiffServ or IntServ as they would not care how the 
information used by them arrives at a router. RSVP WG studies RSVP by its 
very name. However, RSVP, at least as it exists today, is not suitable to be 
used with Mobile IP. And also, its not only a small tweak to it that would 
work. It would be a major revision.

Hemant

>From: Phil Roberts Reply-To: [email-masked] To: 
>"[email-masked]'" Subject: [mobile-ip] QoS Work Item Date: 
>Thu, 29 Mar 2001 16:02:43 -0500
>
>
>We have a charter item to consider the relationship between MIP and QoS. 
>That's pretty vague. We've seen a couple of drafts on this, and actually 
>have a request to make one a working group item. This is premature. The 
>working group needs to consider what exactly we need to do.
>
>Our charter says: "In the longer term, the WG needs to address: - QoS in 
>the mobile IP environment using diff-serv and/or int-serv/RSVP."
>
>The problem is that MNs may be using QoS mechanisms on their flows and 
>these MNs will sometimes move using MIP mechanisms. We have some options to 
>explore about how to address this. We could address QoS issues related 
>specifically to mobile IP in this WG based on QoS work done in other WGs 
>(DiffServ, IntServ). We could just provide requirements from a MIP 
>perspective to WGs working on these QoS mechanisms and ask them to solve 
>it. We could work jointly with folks in other working groups to produce 
>some proposals about how to proceed. It is clear we don't have the option 
>to invent another QoS protocol and we shouldn't be doing this work in 
>isolation.
>
>So, we'd like to know the working group's opinion on the direction we take.
>
>
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: gabriel montenegro <[email-masked]>
Date: Fri, 30 Mar 2001 00:31:30 +0200

> work. It would be a major revision.

did anybody follow or try to submit requirements to the nsis bof?
does that seem like an appropriate venue for this?

http://www.ietf.org/ietf/01mar/nsis-agenda.txt

-gabriel

---

From: Allison Mankin <[email-masked]>
Date: Thu, 29 Mar 2001 18:10:19 -0500

> http://www.ietf.org/ietf/01mar/nsis-agenda.txt

The NSIS BOF did surface a lot of requirements for QoS signaling
in mobile IP.  

Scott and I (the ADs) are starting to formulate a possible
working group that would address the topic.  Watch the IETF
mailing list for an announcement of an nsis discussion mailing
list and more progress soon.

Allison

---

From: "Andrew T. Campbell" <[email-masked]>
Date: Thu, 29 Mar 2001 18:01:34 -0800

I think the application of diffserv control to the
wireless domain make good sense as a starting
point. But there are many open questions there.

Signaling is another issue. May be point-to-point
implicit/explicit signaling makes sense for some
continuous media services with holding times. But for web
data its not practical - but some QOS control
may be need for that web data.

Clearly, there is no divorcing the wireless MAC capability
from the solution space. We found that you could
provide some simple support for wireless diffserv
providing effective admission control:

Barry, M., Campbell, A.T and A. Veres , "Distributed Control Algorithms for
Service Differentiation in Wireless Packet Networks ", Proc. IEEE
INFOCOM'2001, Anchorage, Alaska, 2001

http://www.comet.columbia.edu/~campbell/andrew/publications/papers/infocom20
01.pdf

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Hemant Chaskar
> Sent: Thursday, March 29, 2001 10:20 PM
> To: [email-masked]
> Subject: Re: [mobile-ip] QoS Work Item
>
>
> Hi,

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 30 Mar 2001 09:51:25 -0800

Hello Gabriel,

I did make my 3 minute presentation. FYI, following were the key points.

1. Any mobility-aware signaling protocol must be able to limit the
extent of signaling to only those nodes (in the packet stream path)
affected by mobility.

2. It must be able to provide fast response time. This includes how
quickly the protocol is able to detect that the mobile node has moved,
as well as the how fast the protocol itself is.

3. It should be able to make use of intrinsic IP mobility signaling.

Regards,

-Rajeev

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Mar 2001 10:29:19 -0800 (PST)

> extent of signaling to only those nodes (in the packet stream path)

   This is a tautology though. I believe that the
   desirable characteristic is that the QoS
   reestablishment converges locally. If we need
   to go clear back to the CN (which also fits
   your definition), speed of light considerations
   may produce unacceptible results.
 
 > as well as the how fast the protocol itself is.

   I'll just throw out here that damping
   mechanisms for route flapping are going
   to be problem.
 
 > 3. It should be able to make use of intrinsic IP mobility signaling.

   This is a huge leap. In fact as it currently
   stands, there is no need for a mobile to have
   any mobility signaling local to its attachment
   point. That, if anything, argues for just the
   opposite: we should not explicitly link QoS
   signaling to mobility signaling.

		Mike