Subject: Re: [NSIS] Comment on draft-fodor-intserv-wireless-issues-00.txt

From: [email-masked] (Gabor Fodor)
Date: Wed, 28 Nov 2001 11:11:56 +0100 (MET)

Marcus,

> From [email-masked] Wed Nov 28 10:29:16 2001
> Date: Wed, 28 Nov 2001 10:39:12 +0100
> From: Marcus Brunner <[email-masked]>
> To: Gabor Fodor <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [NSIS] Comment on draft-fodor-intserv-wireless-issues-00.txt
> 
> Gabor,
> 
> I try to sumarize the scenarios you scetched, hope I understood your 
> scenario right.
> - From an IP point of view, the Wireless access network in transparent.
> - The first box understanding IP again is the WAN GW
> - layer 2 is able to create a channel/connection/... from UE to WAN GW with 
> some caracteristics (bw,...)
> - IP QoS signaling MUST interwork with the layer 2 signalling? Including 
> mapping of QoS parameters on l3 to l2.
> 
"MUST" depends on the requirements: if we consider it important that 
applications can run resource (spectrum) efficiently over 
wireless networks where spectrum is scarce (e.g. cellular), then it
is very useful if "wireless hint" parameters are provided in the QoS
signaling. The point is to determine these wireless hints such that 
application developers can understand and make use of it and at the 
same time they provide sufficient information to configure most of
the wireless links. 

> Now some questions
> - who is initating l2 connection setup via signaling
In principle it can be either the terminal or the gateway, but 
I would say that typically I expect it to be the terminal (UE).

> - for me it is not that L2 independent
I am nost sure what you mean here. I expect the terminal to have a L2
driver if the terminal is to support transport over a L2 connection.
For instance, a wireless PCMCIA card could have the L2 specifics.
The wireles hints are L2 independent but should be determined such that
a small set of such parameters is useful for most of the resource critical
(typically wireless) links.

> - Do we really need to integrate L2 L# signaling interworking? Does it make 
> sense to do L2 based on other mechnisms (fixed depending on subscription, 
> user configured, static for a given network etc.)
We do not integrate L2 signaling into L3 signaling in any ways However,
at the IP layer we should have some parameters that help the L2 resource
manager to configure the L2 link in cases where it needs information about
the traffic and the QoS it is expected to support. Otherwise, L2 
resources cannot be managed in an efficient way and in a resource scarce
environment it may mean increased costs for the users. Other environments
could simply ignore these hint paramaters. 

> Marcus
/Gabor

> 
> --On Tuesday, November 27, 2001 5:05 PM +0100 Gabor Fodor 
> <[email-masked]> wrote:
> 
> >
> > John,
> >
> > our draft addresses the issue of what QoS parameters need to be
> > signaled, rather than discussing a particular resource reservation
> > mechanism or a particular layer 2 technology. The draft points
> > out that for some layer 2 technologies (including some wireless)
> > the signaled parameters need to provide detailed traffic/QoS
> > information such that the underlying layer can be configured
> > appropriately. I agree with you that we would need to be more clear
> > on this point.
> >
> > Please see some further reflections below :
> >
> >> From [email-masked] Tue Nov 27 14:08:37 2001
> >> From: [email-masked]
> >> To: [email-masked]
> >> Cc: [email-masked]
> >> Date: Tue, 27 Nov 2001 15:07:50 +0200
> >> MIME-Version: 1.0
> >> Subject: [NSIS] Comment on draft-fodor-intserv-wireless-issues-00.txt
> >> X-Mailman-Version: 1.0
> >> List-Id: Next Steps in Signaling <nsis.ietf.org>
> >> X-BeenThere: [email-masked]
> >>
> >> Gabor, Fredrik & Brian,
> >>
> >> Some comments on your draft:
> >>
> >> http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issues-
> >> 00.t xt
> >>
> >> My first, high-level comment is that I am somewhat confused about
> >> the applicability of this work for NSIS.  It seems that you are
> >> looking specifically at Resource Reservation (Intserv) and layer
> >> 2 (cellular).  Those issues are out of scope.  If the intention
> >> was to provide some insight into the NSIS problem area based
> >> upon this particular area, some text stating such would be
> >> useful.
> > Yes, we need to add some text here. Again, the intention is to
> > contribute to one of the issues mentioned in the charter (3rd
> > paragraph) :
> >
> > "what sort of QoS parameters to use"
> >
> >>
> >> In section 2 - General Background, you state:
> >>
> >>    The Appendix develops a model for the radio access network ...
> >>
> >> Is this model the basis for some implementation or simulation
> >> work?  If so, including the results of such studies would
> >> be useful, otherwise it seems that you a proposing an
> >> architecture, which IMO, would be out of scope for NSIS.
> >>
> > The appendix is for information only and attempts to develop
> > an abstract model to help discussions on what parameters are
> > needed to configure a QoS enabled radio bearer. As such, we
> > are not proposing it as an architecture.
> >
> >> Small nit: try not to split diagrams across page breaks
> >> (see figure 1 & 2).
> >>
> >> Additionally, while I am familiar with 3G architecture, I
> >> don't know if everyone is.  It might be much more useful
> >> to show a more functional-type architecture.  For example,
> >> RNCs do quite a bit, and even though they are shown as
> >> a network element in the 3GPP architecture, they may, in
> >> fact be shown as quite seperate functions within an
> >> architecture.
> >>
> >> I have a small bit of trouble with this statement:
> >>
> >>    In wireless networks, the physical resources (e.g. frequency
> >>    spectrum, transmission power or time slots) are typically scarce.
> >>    The transmission is therefore optimized in order to utilize the
> >>    resources as efficiently as possible.
> >>
> >> Wireless can be considered as a layer 1 / layer 2 issue.  Is
> >> it more scarce than copper on a dial up connection?  Somehow,
> >> I would say it is good design practice to make protocols
> >> that are conservative in what they send ...
> >>
> > Yes, I agree with you. However, the wireless resources and the
> > wireless layer 2 bearers can be configured dynamically using signaled
> > parameters, and therefore it is important that these parameters
> > are available. The above text gives some background to this.
> >
> >> Finally, in section 6 - Security Considerations, you have listed:
> >>
> >>    None
> >>
> >> Are you sure about that?  There will have to be considerations
> >> about if the user is authorized to gain the resources desired,
> >> by allowing levels of QoS, there is the possibility of DoS-style
> >> attacks by monopolizing resource, etc.
> >>
> > I agree. Since we were trying to focus on the parameter aspects,
> > we don't see security issues directly related to those. However,
> > I expect the protection against DoS attacks to be an important
> > part of the protocol.
> >
> >> best regards,
> >> John
> >>
> > Regards /Gabor
> >
> >> _______________________________________________
> >> nsis mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/nsis
> >>
> >
> > _______________________________________________
> > nsis mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nsis
> >
> 
> 
> 
> --------------------------------------
> Dr. Marcus Brunner
> Network Laboratories
> NEC Europe Ltd.
> 
> E-Mail: [email-masked]
> WWW:    http://www.ccrle.nec.de/
> personal home page: http://www.brubers.org
> 
> Adenauerplatz 6
> D-69115 Heidelberg
> Germany
> 
> Phone: +49 (0)6221/ 9051129
> Fax:   +49 (0)6221/ 9051155
> 
> 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Marcus Brunner <[email-masked]>
Date: Wed, 28 Nov 2001 12:09:35 +0100

--On Wednesday, November 28, 2001 11:11 AM +0100 Gabor Fodor 
<[email-masked]> wrote:

>> - layer 2 is able to create a channel/connection/... from UE to WAN GW
>> with  some caracteristics (bw,...)

I know that this is part of the reqs, but wanted to know, whether you 
regard it a MUST.

> (typically wireless) links.

If I understood your draft, you look into the case where L2 itself can 
setup a connection with various characteristics (e.g. bit errorer rate as 
in W-CDMA)

MArcus

>> - Do we really need to integrate L2 L# signaling interworking? Does it
>> make  sense to do L2 based on other mechnisms (fixed depending on
>> subscription,  user configured, static for a given network etc.)
>> >> http://www.ietf.org/internet-drafts/draft-fodor-intserv-wireless-issu
>> >> es- 00.t xt
>> >>

Adenauerplatz 6
D-69115 Heidelberg
Germany

---

From: Brian Williams <[email-masked]>
Date: 29 Nov 2001 11:18:52 +1100

On Wed, 2001-11-28 at 22:09, Marcus Brunner wrote:
<snip>
> setup a connection with various characteristics (e.g. bit errorer rate as 
Yes, there is an L2 manager that must decide when to establish L2
bearers. Since each L2 bearer has an associated QoS, it must in effect
be controlled by the QoS requirements from the applications. That is, if
the applications have no specific QoS requirements, then a generic
bearer shared with other apps can be used for that traffic. If the app
identifies specific QoS requirements, then something must decide if that
can be met using an existing bearer (with some form of sceduling
control) or a separate bearer. Thus, this is triggered from application
QoS requests.
 
> > could simply ignore these hint paramaters.
I agree with this comment. We are not integrating the signalling here,
and there are separate functions controlling the L2 bearers and the IP
bearers. However, there are requirements that they interact reasonably
(L2 requires sufficient information about the IP traffic and QoS
requirements, and the IP layer requires information about the L2
characteristics).
/brian