Subject: [mobile-ip] QoS Work Item

From: Phil Roberts <[email-masked]>
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.

---

From: James Kempf <[email-masked]>
Date: Thu, 29 Mar 2001 14:31:43 -0800 (PST)

Hi Phil,

I believe there was a Next Steps in Signalling BOF at IETF 50 where many people
presented requirements for mobile QoS. I do not know what the outcome
of that BOF will be, but I think we should work together with them,
closely, to make sure the next QoS signalling protocol meets the
needs of mobile IP.  If we do make any QoS drafts working group
drafts (and I will reserve my opinion on whether that should be done
until I know the draft), I think they should be informational only.

My 0.02 won.

		jak

---

From: "Haseeb Akhtar" <[email-masked]>
Date: Thu, 29 Mar 2001 16:42:39 -0600

Phil,

It is obvious from the long email exchanges that we have seen 
before the IETF week that the QoS groups, at least as it 
exists today, may not necessarily cater to the problems/perspectives
that are germane to mobility. 

Having said that, I also believe we should utilize the rich 
experiences of the intserv/diffserv/RSVP folks.

I propose this group comes up with the requirements and then form
a design team (that comprises of the both sides - QoS groups and us) 
to come up with a solution.

Regards,

Haseeb

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 30 Mar 2001 14:13:30

Yes we did intimate some of these requirements in NSIS BOF at IETF 50 (we 
had only 3 minutes though :-(.

>From: gabriel montenegro <[email-masked]>
>Reply-To: [email-masked]
>To: [email-masked]
>Subject: Re: [mobile-ip] QoS Work Item
>Date: Fri, 30 Mar 2001 00:31:30 +0200
>
>Hemant Chaskar wrote:
>
> > 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.
>
>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
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

---

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 30 Mar 2001 14:33:01

Hi,

I tend to think that signaling is the main issue. More so if we want our 
solution to be compatible with the techniques developed in other QoS WGs 
such as MPLS, DiffServ, IntServ, ISSLL and so on. Clearly, no or minimal 
signling would be needed for web transactions. However, signaling will be 
essential for say VoIP call, an important application from mobile terminals. 
We should not be developing wireless diffserv vs diffserv that exists today. 
Also, the QoS signaling must be intelligent enough to trigger end-to-end QoS
programming whenever needed and refrain from doing so when it is not needed. 
An example of the former case is the handover from indoor LAN to cellular 
network. In that case, the path of packets in the core will change as well. 
An example of the latter case will be micro-mobility. In other words, our 
thinking should not be limited to access side alone.

(Aside:

Thanks for informing about the Infocom paper. Frankly, I have not read it 
yet, but will do so soon. I would also like to point to another paper 
related to wireless diffserv:

A framework for QoS differentiation on 3G CDMA air interfaces, by Yile Guo 
and Hemant Chaskar, IEEE Wireless Comm. and Networking Conference (WCNC), 
September 2000.

)

Regards,
Hemant

>From: "Andrew T. Campbell" <[email-masked]>
>To: <[email-masked]>
>Subject: RE: [mobile-ip] QoS Work Item
>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
>
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Hemant Chaskar
> > Sent: Thursday, March 29, 2001 10:20 PM
> > 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.
> >
> > 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
> > 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
> > >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.
> > >

---

From: Fred Baker <[email-masked]>
Date: Fri, 30 Mar 2001 07:30:43 -0700

>to come up with a solution.

I'd be willing to work with such a working group or design team.