Subject: RE: RSVP on wireless IP

From: Yoram Bernet <[email-masked]>
Date: Mon, 3 Apr 2000 08:07:57 -0700

I tend to view 

> -----Original Message-----
> From: Simon Oosthoek (EMN) [mailto:[email-masked]]
> Sent: Monday, April 03, 2000 1:10 AM
> To: 'Bora Akyol'; [email-masked]'
> Cc: Geert Heijenk (EMN); Georgios Karagiannis (EMN)
> Subject: RE: RSVP on wireless IP
> 
> 
> > -----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: Yoram Bernet <[email-masked]>
Date: Mon, 3 Apr 2000 08:15:23 -0700

I tend to view wireless as just another link layer over which QoS is
necessary. RSVP is a signaling protocol that is used to request QoS on an
end-to-end basis. It is intentionally, sufficiently abstract to support
concatenated subnetworks of varying media. The ISSLL working group has
defined mappings from RSVP (when it carries Intserv parameters) to various
'link layers' including 802, atm, slow wan, and most recently, diffserv. 

The current model as I see it, is that an RSVP request is generated by an
end system, including a layer-3 abstraction of the QoS it needs. This
request propagates along the traffic path, from sender to receiver (and the
response in return). At various points, admission control 'agents' are
responsible for reviewing the request and comparing it against the resources
aailable in the part of the network for which they are responsible. This
requires these agents to be able to map the abstract intserv parameters into
the parameters appropriate for their specific media, and possibly to
generate some link layer specific signaling. RSVP serves to unify the
disparate QoS mechanisms of the different media. 

I think that wireless should be part of the same general model. I expect
that the wireless 'base station' (or alternate admission conrtrol agent)
would participate in the end-to-end RSVP signaling and would be able to map
RSVP requests to its local QoS mechanisms. The SBM, defined by the ISSLL WG
might be a good model for such participation.

Regards,
Yoram

---

From: "Georgios Karagiannis (EMN)" <[email-masked]>
Date: Mon, 3 Apr 2000 18:10:13 +0200

Dear all

In principle, I agree with Yoram's opinion regarding the fact that
RSVP serves to unify the disparate QoS mechanisms of the different media, including wireless subnetworks.
However, we have not seen any activity of the ISSLL group in the area of QoS mappings from RSVP to wireless subnetworks.
Perhaps it will be a good idea to enlarge the charter goals of the ISSLL group in order to include issues that are relevant to RSVP and wireless networks, e.g., cellular networks.

Best Regards,
Georgios

---

From: Yoram Bernet <[email-masked]>
Date: Mon, 3 Apr 2000 08:07:57 -0700

I tend to view

---

From: Yoram Bernet <[email-masked]>
Date: Mon, 3 Apr 2000 08:15:23 -0700

Regards,
Yoram