RE: [MIP-QOS] Re: MIP-QOS -- Scope of discussions

[marc.greis@nokia.com]

James,

> -----Original Message-----
> From: ext James Kempf [mailto:James.Kempf@sun.COM]
> Sent: 17 April, 2001 7:16 PM

> Re. RSVP v.s. Diffsrv, 	in cellular networks, the radio access
network
> is always oversubscribed because the air is always in scarce supply.
> Thus there is a part of the network that has Intsrv like requirements
> but these are not end to end. They are only in the access network.

This is a very strong statement, which I can not totally agree with. Yes,
radio bandwidth is naturally limited, while in the fixed network, you can
always add another trunk. However, not every operator may have the money to
just add more fixed bandwidth, and they would not necessarily agree that
"IntServ like requirements" end at the wireless base station.

> Thus, I have some trouble seeing why RSVP is needed end to end, and
> I think it is somewhat heavyweight even for the access network,
> since the signalling in the handoff case is very subotimal (please
> see Michael Thomas's draft on this). Note that I am not saying that
> the IP QoS signalling should directly cause the radio QoS to
> get established (that is a separate, and very interesting topic
> on its own) but just simply that there needs to be signalling that
> allows RSVP-like reservations hooked to the radio QoS mechanism.

I think we should probably leave any considerations about the radio access
out of the discussion and just assume that there is a mechanism which allows
a mobile node in a wireless network to set up a reservation similar to an
IntServ reservation in the radio network. I think we should be concerned
about how the QoS in the fixed core network is set up and maintained when
the mobile node moves, and I don't see a reason why we can't see the radio
access network as a black box for that purpose.

> In the core network, Diffsrv works fine, if the service provider
> is willing to overprovision and give up the "all circuits are busy"
message
> that comes a part of end to end QoS. Most service providers seem
> pretty tied to having end to end QoS, though reestablishing that
> on handover is really costly.

That is a very good point and this should probably be one of our
requirements. There are generally two options when the resources get scarce:
Either a new session is blocked, or the quality for all sessions is degraded
to some extent by the new session. I think there are not only service
providers, but also end users (I am one of them) who prefer the latter
option.

> So I think there are three separate issues here:
> 
> 1) How to get signalling that is handover friendly and provides Intsrv
> like properties in the radio access network without requiring the
> entire network to be Intsrv?

I think we should shorten that to "How to get signalling that is handover
friendly". As you said yourself, you don't want the signalling to set up the
radio QoS, so I don't think that we should mention that it provides IntServ
like properties in the radio access network.

> 2) How to match up the above with a DiffSrv like core, like Diff-edge?

At least for RSVP, there is a huge amount of work related to its
interworking with DiffServ networks. The main problem is that RSVP is
currently not handover friendly. We'll have to decide in the future if we
want to fix that problem (or if that problem can be fixed).

> 3) How to do handover friendly, end to end QoS for those service
> providers that don't want to overprovision and want to provide
> the "all circuits" message?

Again, I agree here.

Marc