Subject: RE: RSVP on wireless IP

From: "Simon Oosthoek (EMN)" <[email-masked]>
Date: Mon, 3 Apr 2000 10:09:41 +0200

> -----Original Message-----
> From: Bora Akyol [mailto:[email-masked]]
> Sent: 01 April 2000 06:10
> To: Simon Oosthoek (EMN); [email-masked]'
> Subject: Re: compiling RSVP on linux (2.2.x, Mandrake 6.x/7.x)
> 
> 
> In a wireless environment, what kind of QoS are you planning 
> on utilizing. 
> Reserved bandwidth, or BER, or CIR type.

I haven't looked at the details for QoS over wireless IP yet, so I can't answer this.

> Do you think that RSVP is a good match for a wireless 
> environment when the 
> channel varies rapidly?

It rather depends on the technology used for the wireless access method. I do believe the MAC layer should provide some handles for QoS aware operation.

> Do you think that RSVP will provide the necessary API so that 
> you can use 
> time-varying error-correcting codes based on BER?

Is that something that should be taken care of in RSVP?
 
> How are you planning on differentiation congestion loss from 
> link layer 
> corruption?

Good question ;-) I think MAC layer awareness of QoS should be able to help here. Or just knowing about MAC layer packetloss...
 
> I guess what I am trying to say is that I don't think RSVP meets the 
> requirements for dynamic wireless channels, you may be much better of 
> proxying RSVP requests via an agent architecture
> that sits at the two end of the wireless connection.

But that would mean that you have at least one hop without QoS support in the RSVP connection. That could break the entire QoS for that flow. The least you can do is try to support QoS awareness in the wireless link, if it then fails for any reason, then you call it static ;-)

> Also you may want to bring this up in the PILC group.

I think I know too little of this to make a useful contribution yet, but I'll keep it in mind.

Thanks for your comments, I'm looking forward to more discussions on this subject, especially when I know more....

Cheers

Simon

---

From: Duncan Thomson <[email-masked]>
Date: Tue, 04 Apr 2000 16:02:50 -0400

The questions raised in this message are ones that we have been tackling here at
MITRE in an ongoing research project.  I'm a bit hesitant to jump into the fray
here, because we haven't published anything on our work yet.  But we're
currently preparing some papers for submission, and we're far enough along that
I thing we have some valuable experience we can contribute to the discussion. 
So here goes...

One question being discussed was suitability of RSVP for wireless environment

> > environment when the channel varies rapidly?

I would extend this question as follows: "Is a resource reservation-based
approach to QoS applicable to a dynamic environment?"  In other words, if
resources (in particular link bandwidths) are constantly changing, how can you
make a reasonable admission control decision that will remain valid for the
duration of a flow?

We think the answer to this question is to build on the concept of reservation
ranges proposed by Songwu Lu and Vadavur Bharghavan in a SICCOMM '96 paper. 
Reservation requests specify a range of bandwidths that the application can
operate in, and the network provides a reservation somewhere in this range,
which can be adjusted as network conditions vary.

Our approach uses the concept of reservation ranges as follows.  First, the
application signals to the network the range of bandwidth that it is capable of
operating in.  The network then reserves resources somewhere in this range, and
signals to the application the end-to-end allocation.  The application then
adapts its behaviour to conform to this allocation, which may change during the
course of the connection.

Obviously, this is not exactly RSVP.  However, RSVP could be extended to
implement the concept, and here at MITRE we have done exactly that.  We now have
a working implementation we call "Dynamic RSVP" (dRSVP), with an extended API we
call "Dynamic SCRAPI" (dSCRAPI), together with adaptive versions of streaming
video and audio applications (modified versions of vic and vat).  We can
demonstrate adaptive QoS in an environment where link characteristics change
during the course of a connection.

Note that I'm not proposing that the RSVP standard needs to be extended or
modified at this point in time.  I'm saying that RSVP as it currently stands
does not include the concept of reservation ranges, that this concept is
valuable in dealing with network dynamics, and that RSVP could be extended to
include this concept.  Whether, and and what point in time, we would want to
think of tinkering with the RSVP standard to handle this is a separate question
that I think would be premature to discuss at this point.

Another issue being discussed was the necessary interaction between RSVP and
lower layers:

"Simon Oosthoek (EMN)" wrote:
> > link layer corruption?
> Good question ;-) I think MAC layer awareness of QoS should be able to 
> help here. Or just knowing about MAC layer packetloss...

Distinguishing congestion loss from link layer corruption is difficult.  We
struggled with this one, and came to the conclusion that it is important to have
explicit signaling between the MAC and RSVP so that RSVP knows what the current
link bandwidth is.  Note that ISI's RSVP daemon reads link bandwidths from a
configuration file on startup - it has no way of knowing when link conditions
change.  I suspect that other implementations are similar.  This is a big
problem in a dynamic environment.

So I agree fully with Simon that MAC layer awareness of QoS requirements is
important, together with appropriate communication between the MAC layer and
RSVP.  You might want to take a look at the work that was done in the DARPA
GloMo project to define router/radio APIs.

In addition, I think it's important to deal with errors within the link layer,
so that the network layer sees only a varying effective link bandwidth.  This
relates to another point that Simon and Bora were discussing:

Bora:
> > you can use time-varying error-correcting codes based on BER?
> 
> Is that something that should be taken care of in RSVP?

I think the answer that the MAC layer should include mechanisms (perhaps things
like adaptive error-correcting codes, but other adaptive mechanisms are
possible) so that the network layer QoS mechanism can have a simplified model in
which error conditions stay "good," while effective throughput (and possibly
other characteristics such as delay) are signalled from the MAC layer via an
appropriate API.  This is the approach we have taken in our dRSVP
implementation.

Duncan Thomson

---

From: Maria Elena Villapol <[email-masked]>
Date: Wed, 05 Apr 2000 16:10:06 +0930

> make a reasonable admission control decision that will remain valid for the

I agree

> relates to another point that Simon and Bora were discussing:

I got confused. Why should RSVP distinguish between congestion loss and link layer
disruption?. RSVP is just a signaling protocol. I think that it is responsibility
of other components of the IntServ architecture such as traffic control (eg packet
scheduler  and admission control). I don't know if when you say RSVP you refer to
RSVP and traffic control components ?.

Maria

--
Maria Elena Villapol
PhD Student
Institute for Telecommunications Research
University of South Australia

email: [email-masked]
       [email-masked]

Web Page: http://www.itr.unisa.edu.au/~maria/index.htm

---

From: Duncan Thomson <[email-masked]>
Date: Wed, 05 Apr 2000 09:37:59 -0400

Let's see if I can straighten out the thread a little here.  Taking a little
liberty with the order in which things were discussed:

> Bora Akyol wrote: 

> Duncan Thomson wrote:
> > In addition, I think it's important to deal with errors within the link
> > layer, so that the network layer sees only a varying effective link 
> > bandwidth.
> 

Maria Elena Villapol wrote:
> 
> I got confused. Why should RSVP distinguish between congestion loss and link
> layer disruption?. RSVP is just a signaling protocol. I think that it is
> responsibility of other components of the IntServ architecture such as
> traffic control (eg packet scheduler  and admission control). I don't know
> if when you say RSVP you refer to RSVP and traffic control components ?.
> 

Maria, 

Yes, I was including components such as admission control when I used the term
"RSVP".  Perhaps my terminology is not correct.  Since I've been working for a
while with ISI's RSVP implementation, I tend to lump together in my mind
everything that is handled by the RSVP daemon (rsvpd) and refer to that as
"RSVP".

Anyway, the point is that there is a major distinction between congestion loss
and link layer disruption.  The intserv architecture is intended to deal with
the former.  The latter should (I believe) be dealt with either within the link
layer, or all the way up at the transport layer.

The reason we got into the discussion is that in some environments link
characteristics change with time.  For example, V.90 modems will "retrain"
during the course of a connection, changing the data rate but maintaining link
quality.  RSVP (admission control) needs to know the link characteristics so
that it knows what resources are available for reservation.  To be specific, it
needs to know the link bandwidth.  Knowing this, RSVP can allocate bandwidth to
flows in such a way as to prevent congestion loss.  My view is that, if the link
is variable, then changes in link bandwidth need to be signalled to RSVP, and
RSVP needs to have some mechanism for dealing with them.  

The picture gets much more complicated in the case of shared media.

Duncan