Subject: Re: [MOBILE-IP] Questions/Comments on Buffer Management draft

From: Mohamed Khalil <[email-masked]>
Date: Thu, 28 Oct 1999 11:20:16 -0500

Hi  Binary,

        Thanks for reading the buffer draft. I hope that I made issues
clearer after answering your questions.

> -----Original Message-----
> From: BINAR, Simon [SMTP:[email-masked]]
> Sent: Thursday, October 28, 1999 8:58 AM
> To:   [email-masked]
> Subject:      [MOBILE-IP] Questions/Comments on Buffer Management draft
>
> Hi.
>
> I have read the buffer management draft, and would have a couple of
> questions/comments:
>
> First, it is not clear to me from Figures (1) and (2) whether the MN is
> communicating directly with the old FA (after it has exchanged messages
> with the new FA), or whether it is communicating via the new FA. If the
> first case applies (direct communications), then the implementation of
> the protocol might be problematic in TDMA-based networks, as it would
> mean that the MN would need to switch several times between different
> frequencies. This would be very inefficient, and could significantly
> increase handover latency. In some cases, it may not be possible at all.
> I think that IP-based solution for handover should not be optimised for
> a particular radio technology (which would be rather CDMA-based networks
> in this case).
>
        Nortek> In our draft we have mentioned different scenarios where our
buffering protocol can be used to cover different radio technologies. So,
the first scenario which is covered by Figure 1 does not fit DMA technology
but it fits more DMA technology. The second scenario which is covered by
Figure 2 fits DMA technology more.

> I think there are also two major issues with this proposal, and I would
> be happy to hear anyone's views on this.
>
> The first issue is related to billing and charging and network
> operator's control over QoS. In public service provider networks, the
> allocation of specific resources to customers (such as bandwidth)
> usually will be reflected in the cost of the service. A buffer is also
> clearly such a resource. Thus, if a MN requests usage of a buffer from a
> service provider, this normally should result in higher cost of the
> wireless service - not only because of usage of dedicated resources in
> the network, but also because the sensed QoS probably will be higher
> (customers cannot be charged the same price for different QoS).
>
> The problem with this approach is that control over the provided QoS is
> in the control of the user rather than the network operator (this is
> what the draft seems to suggest, anyway). If a user requests usage of
> buffers, he will need to be made aware of the higher cost. How shall
> this happen? I think this is a very difficult issue to resolve. The
> easier way would be for the user to *sign-up* a priori for a service
> with a specified QoS. A foreign agent could then decide whether it
> should allocate buffer space based on the QoS class that is specified in
> IP packet headers (e.g., the DS field in the case of DiffServ, I guess).
>
> Furthermore, if the network operator knows a priori how many customers
> have signed up for a specific class of service, it will have a rough
> idea of how to dimension its network, and especially about how much
> buffer space to allocate in its foreign agents. How shall the network
> operator do network dimensioning when *anyone* could use available
> buffer space? How could the operator then provide different levels of
> service to different customers? If anyone can request use of buffers,
> then users that otherwise would have payed more money for higher service
> might not get the service they expect, because someone else is using up
> their resources... These are all quite tough issues, I think.
>
> My point here is that control over QoS should be for a large part in the
> hands of the network operator, and not of the user.
>
        Nortek > Actually our drafts agree completely with your point of
view that the network operator should have full control over the size of the
buffer allocated for the user. when The user  signs up an LA with ISP he
will be offered a maximum buffer size according to the service he requires
and he pays for. The user before he starts up a session he can ask for a
certain buffer size from the network operator the network operator will not
offer him more than it is stated in Th LA.
> Another problem is from the perspective of application developers. The
> proposed buffer management draft provides a lot of flexibility to the
> mobile node to request or not usage of buffer space, to specify how much
> buffer space is needed, to request or not whether the foreign agent
> should send a Buffer Control Response or not, etc... This high level of
> flexibility in my view also means a lot of headaches for application
> developers, because they will be confronted with the basic question: how
> should they choose which values to use for all of these
> options/parameters?
>
        all what we have are three options I don't think that specifying
three values is a lot of headaches as you mentioned. If the application
developers decided not to specify any of the three values the default values
will be considered automatically for him.
> Comments are most welcome...
>
> ----------------------------------------------
> Simon Binar
> NEC Europe Ltd.
> Tel:   +44 (0)1753 606933
> Fax:   +44 (0)1753 606901
> EMail: [email-masked]
> -----------------------------------------------
> DISCLAIMER:  Any views or opinions expressed in
> this E-Mail message should be considered as the
> personal views/opinions of the author.  They do
> not  necessarily  represent  the  views  of the
> author's employer.
>
>
        Mohamed M Khalil
        IP Mobility Group
        Nortek Networks

---

From: [email-masked]
Date: Thu, 28 Oct 1999 11:58:07 -0600

Claude,

Diffserv does NOT mean that anyone can mark their markets with the DSCP
which points to the best PHB and gets that service without any prior
subscription. Instead, the diffserv provider checks the traffic from the
user (this can be another diffserv domain or a host) against a previously
negotiated SLA. If you exceed what you asked for, then the provider either
does what was agreed in the original SLA (if this was already negotiated) or
performs a default behavior, e.g., dropping, remarking, etc. Obviously, it
does not matter whether this host is stationary or mobile. (This far
explains how traffic originates from the host is handled.)

For the diffserv traffic destined towards a mobile host, things are not that
different with the exception that traffic conditioning may have to be
applied by the diffserv provider at the egress, i.e., closer to the wireless
link. The decision about shaping or dropping, i.e., the size of buffer
space, is again dependent on the SLA between the host and the diffserv
provider.

As Simon said, the SLA between the host and the diffserv provider has to be
negotitated. Possibly there will be static limits on this SLA (due to
terminal hardware limitations, network infrastructure limitations and
budgetary constraints of the user :)), as well as dynamic limits due to the
current load in a particular geographical area. However, the SLA does not
have to be static and can always be renegotiated on demand by the host or
the network. Certainly, the buffer size can be a part of this negotiation.

Regards,

Murat Bilgic
Omnipoint Technologies, Inc.  Tel:719-884 2492
1365 Garden of the Gods Road  Fax:719-548 1393
Colorado Springs, CO 80907

> From: Claude Castelluccia [mailto:[email-masked]]
> Sent: Thursday, October 28, 1999 10:12 AM
> To: [email-masked]
> Subject: Re: [MOBILE-IP] Questions/Comments on Buffer Management draft
>
>
> BINAR, Simon wrote:
> Hello,
> the same problem occurs when trying to use DiffServ in a mobile
> environment...
> we just have to hope that statistical multiplexing will help us ...
>
> Claude.
>
> ----------------------------------------
> Claude CASTELLUCCIA, INRIA Rhone-Alpes
> ph:  +33 4.76.61.52.15 (fax: 52.52)
> http://www.inrialpes.fr/planete/
>