Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement s for Mobile IP

From: "Hemant Chaskar" <[email-masked]>
Date: Fri, 15 Jun 2001 17:09:22

Hi Murat:

Some answers inline.

>From: "Bilgic, Murat" <[email-masked]>
>Reply-To: [email-masked]
>To: "[email-masked]'" <[email-masked]>
>Subject: RE: [mobile-ip] New Internet Draft Notification - QoS requirement  
>s for Mobile IP
>Date: Tue, 12 Jun 2001 17:24:50 -0700
>
> > >Also do you think, if
> > >the MN should be able to resolve such conflicts based on only local
> > >knowledge or does it require the network's assistance while making that
> > >decision? (As you may guess, I'm trying to state this as a requirement
> > not
> > >as some form of design parameter.)
> >
> > [HC] So much of a detail tends to drive us into solution space and 
>reduces
> >
> > the flexibility of solution design.
>	[MB]  I disagree on this one. But probably I should clarify my
>reasoning. I see the two ends of the spectrum of solutions  as follows:
>	1. MN does not need any authorization prior to a mobility event for
>QoS. Therefore, the network is (over-)provisioned to accommodate such
>events. Obviously this does not mean that after the mobility event, the
>network can't force a degradation in the provided QoS, but the application
>demanding QoS has a much longer time to adopt itself. The benefit I see for
>this end of the spectrum is potentially faster and simpler mobility. BTW,
>this was what I was referring as "local knowledge".
>	2. MN needs authorization, i.e., negotiation with the network prior
>to a mobility event for QoS. Therefore, the network is provisioned just the
>"right amount". However, the mobility mechanism is most likely more complex
>and slower. In addition, the application has to react much faster to
>degradation in the provided QoS. Again, this was what I was referring to as
>"network assistance".
>
>	In my opinion, there is a very big difference between these two
>approaches. If you are saying the requirement is so broad such that any
>solution within this spectrum would be acceptable, then I'd have difficulty
>accepting the value of requirements development phase.

[HC] This issue had surfaced on the mailing list. At that time, the 
concensus was that we would work from a point onwards when the target AR for 
handover is "pinned down". That is also the working assumption in some other 
task items such as fast handover and context transfer. Now pinning down the 
target AR for handover may involve negotiation phase as you have described 
in one extreme case or "I am going there anyway" case as you have described 
in the other extreme case. The task of pinning down the target AR may be 
solved in other task items such as candidate access router discovery task 
item of Seamoby charter. In any case, if the new AR cannot provide QoS that 
was obtainable from the old one, MN applications have to reach to it. Some 
people thought of it as not necessarily the Mobile IP specific requirement, 
rather a general area of elastic applications when network QoS degrades. 
However, in my opinion this event will happen more often in mobile 
environments. So, if people think that something to that effect must be 
included in the requirements, I will do that.

>
> > >
> > >4. How should I intrepret your requirement on heterogeneous end-to-end
> > >packet paths? Does it mean that the MN has to be aware of the entire
> > >network
> > >topology, e.g., where diffserv, intserv, MPLS or any other mechanism is
> > >used
> > >and how and where it is interworked? Since I don't currently have to do
> > >that
> > >for my non-mobile host, I wonder again why is this requirement imposed
> > for
> > >mobile hosts?
> >
> > [HC] There is no QoS in Internet today, and that's why you do not have 
>to
> > do
> > it for your non-mobile host.
> >
> > Further, if you have a static host, it is possible to configure in it 
>the
> > QoS functions that the access network expects the host to perform and
> > those
> > functions are not going to change during the ongoing session. For 
>example,
> >
> > the service provider can tell you that it uses DiffServ in access and 
>can
> > give you a configuration file that tells what port numbers to use for 
>say
> > EF
> > traffic so that the network can classify that traffic. In the mobile 
>case,
> >
> > the MN may move across differnt access networks.
> >
> > Also, believe me that some knowledge about the end-to-end packet path is
> > required for end-to-end QoS. The host may not have this knowledge but 
>the
> > network needs to have it. It could be by virtue of SLAs between DiffServ
> > domains, or such knowledge can be acquired by RSVP signalling {RFC 2998)
> > over a mix of IntServ and DiffServ networks.
>	[MB]  I don't dispute that end-to-end QoS requires some form of
>capability to signal what you are looking for from the MN's side or what 
>you
>should use from the network side. However, as articulated quite 
>convincingly
>in RFC 2990, it's quite hard to imagine one framework, i.e., a holy grail 
>to
>solve this problem. If (at least as of today it's true) there is no 
>unifying
>QoS framework for Internet, then I'd say the argument for one for mobile
>hosts is pretty weak. Instead, wouldn't it be better to put together a more
>limited requirement stating that a network's QoS capabilities are used in
>determining the mobility decision within the MN. In this case, there is no
>reason for a "one-size fits all" QoS solution and MNs would still make
>informed decisions. In addition end-to-end QoS mechanism(s) can be kept
>entirely separate from mobile IP. What do you think?

[HC] I think this is a good suggestion. We can phrase it something like 
this:

Network's QoS capabilities SHOULD be used in determining the mobility 
decision within the MN. "One-size fits all" may not be a good approach as 
you have rightly suggested. Let me think more about it before formulating 
the right kind of requirement.

> > >
> > >Thanks in advance for your answers,
> >
> > [HC] I hope this clarifies some of your concerns. Thanks for your
> > comments.
> >
> > [Hemant]
>	[MB]  Thank you,
>
>	Murat Bilgic

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

---

From: Charles Qi Shen <[email-masked]>
Date: Mon, 18 Jun 2001 17:59:16 +0800

Hi,

I quite agree with the argument "There is no reason for a "one-size fits 
all" QoS solution". However the following sentence sounds confusing to me,

"Network's QoS capabilities SHOULD be used in determining the mobility 
decision within the MN. "

Don't we have both Network determined and MN determined handoff scenarios 
for mobility? So why only say within MN?

Charles

At 05:09 PM 6/15/2001 +0000, you wrote:
>> > [HC] So much of a detail tends to drive us into solution space and reduces
>> >
>concensus was that we would work from a point onwards when the target AR 
>for handover is "pinned down". That is also the working assumption in some 
>other task items such as fast handover and context transfer. Now pinning 
>down the target AR for handover may involve negotiation phase as you have 
>described in one extreme case or "I am going there anyway" case as you 
>have described in the other extreme case. The task of pinning down the 
>target AR may be solved in other task items such as candidate access 
>router discovery task item of Seamoby charter. In any case, if the new AR 
>cannot provide QoS that was obtainable from the old one, MN applications 
>have to reach to it. Some people thought of it as not necessarily the 
>Mobile IP specific requirement, rather a general area of elastic 
>applications when network QoS degrades. However, in my opinion this event 
>will happen more often in mobile environments. So, if people think that 
>something to that effect must be included in the requirements, I will do that.
>
>>
>> > >
>> > [HC] There is no QoS in Internet today, and that's why you do not have to
>> > do
>> > Further, if you have a static host, it is possible to configure in it the
>> > functions are not going to change during the ongoing session. For example,
>> >
>> > the service provider can tell you that it uses DiffServ in access and can
>> > give you a configuration file that tells what port numbers to use for say
>> > EF
>> > traffic so that the network can classify that traffic. In the mobile case,
>> >
>> > required for end-to-end QoS. The host may not have this knowledge but the
>>capability to signal what you are looking for from the MN's side or what you
>>should use from the network side. However, as articulated quite convincingly
>>in RFC 2990, it's quite hard to imagine one framework, i.e., a holy grail to
>>solve this problem. If (at least as of today it's true) there is no unifying
>[HC] I think this is a good suggestion. We can phrase it something like this:
>