RE: Providing QoS through current link layer primitives
Hi, Michael
As AV Bridging group states in their website:
'There are currently no active PARs for AV Bridging. Authorization for
several is expected over the next few months.'
The 802.1AS PAR is the first one of these expected several ones. The
synchronization is the first step in achieving QoS support in the Ethernet,
and thus make it possible to have a hold on delay, delay variation and
wander characteristics. Later on comes other QoS aspects in the coming PAR's
if I haven't misunderstood something.
Since the handover between wireless 802 access medias (.11, .16, maybe
others) and .3 are within the scope of .21, it definitely does not harm to
mention in the architecture coordination meeting what is currently being
discussed in .21 around the QoS area.
BTW, the referred submission will be updated for the Denver meeting, among
other things to better indicate how .21 could cooperate with IETF NSIS.
Best Regards, Reijo
-----Original Message-----
From: stds-802-21@ieee.org [mailto:stds-802-21@ieee.org] On Behalf Of
Michael.G.Williams@NOKIA.COM
Sent: Sunday, March 05, 2006 5:39 AM
To: mperesse.ext@RD.FRANCETELECOM.COM; STDS-802-21@listserv.ieee.org
Cc: tony@JEFFREE.CO.UK
Subject: RE: Providing QoS through current link layer primitives
Colleagues,
In reviewing the slides submitted with this work on application and link
QoS:
http://www.ieee802.org/21/march06_meeting_docs/21-06-0493-02-0000-Threshold_
Parameters_Survey.ppt
there is a reference to the 802.1AS PAR and potential requirements /
comparisons that might arise from that work. Is there indication that
residential ethernet synchronization should be considered as an aspect of
QoS relevant to handover? If so it can be mentioned at the Sunday
architecture coordination meeting to see what next steps might be useful.
Best Regards,
Michael
-----Original Message-----
From: ext zze-Seamless PERESSE M ext RD-RESA-REN
[mailto:mperesse.ext@RD.FRANCETELECOM.COM]
Sent: Tuesday, February 28, 2006 1:37 AM
To: STDS-802-21@listserv.ieee.org
Subject: Re: Providing QoS through current link layer primitives
Hi Nada,
Thanks for your answers,
-----Message d'origine-----
De : Nada Golmie [mailto:nada.golmie@nist.gov] Envoyé : lundi 27 février
2006 23:09 À : zze-Seamless PERESSE M ext RD-RESA-REN Cc : Reijo Salminen;
STDS-802-21@LISTSERV.IEEE.ORG; Olvera-Hernandez, Ulises;
nada.golmie@nist.gov Objet : Re: [802.21] Providing QoS through current link
layer primitives
Hello Mathieu,
The MIH QOS framework for 802.21 described in 21-06-0493-02 can be easily
extended in order to communicate the application QOS (static) requirements
to the MIH function and/or decision engine.
I guess we need simply add the "MIH_Configure_QOS" command and event as you
suggest. No other additions are required as far as I can tell.
Multiple parameters can be specified as you suggest in step A. Observe that
these parameters should refer to the MIH QOS pre-defined (or
proposed) list, i.e. IPTD, IPDV, IPLR, and IPER. We can certainly keep some
"reserved for future use".
Some comments/ clarifications on the terminology you use:
1) What you refer to as type 1 QOS are commonly known as application QOS
requirements. These are expected requirements in order for the application
to operate adequately. There are several ITU-T publications that make
recommendations for different class of service/applications.
Thus, these requirements can be known a priori to the MIH or may not be
exchanged on a session by session basis.
[MP] You mean that if an application use "MIH_Configure_QoS" to express its
App QoS requirements, there is no need to specify any values, but rather a
type of service/application ?
2) What you refer to as type 2 QOS are known as network performance
objectives and those are real-time measurements obtained from the network
and made available to the MIH/ decision engine or even the application in
order to perform some action, for example a handover, or no handover.
[MP] OK, here is what I would propose for a start:
- define the 2 types of QoS parameters in the definition section
(application QoS requirements and network performance objectives (perhaps
with ITU-T references)). -
- modify Paragraph 5.1.3 so that it roughly describe what we want to achieve
(not specifically how).
- add MIH_Configure_QoS so that the proposal keeps its consistency.
-Nada
Reijo Salminen wrote:
>Hi, Mat
>
>Thank you for your very fruitful answer.
>
>I agree it would be good to spend some time on the scenarios, it is
>very good input to the group and will help in achieving a good
>understanding of the problematics and thus improve the possibilities to
>come up with a high quality standard in IEEE 802.21.
>
>I warmly welcome to cooperate on this issue further, we could work on
>this during next week so that we would have an updated version of the
>submission to present and discuss further in the group during Denver
>meeting.
>
>Any comments, Nada, Ulises, rest of the group?
>
>BR, Reijo
>
>
>
>
>>HI Reijo,
>>
>>Thanks for your answer.
>>
>>Even if the use cases and scenarios are out of scope, i think it is
>>essential to share them among the group, so that we all grasp the
>>reason why a particular feature needs to be added.
>>
>>I will now present what I have in mind, a particular use case
>>(obviously with some out of scope material..) and then the features
>>needed to make this use case possible through .21:
>>
>>
>>To function properly, certain applications need a minimum level of QoS
>>(for example VoIP or VideoConf). They also need to adapt to condition
>>changes due to the wireless environment. In other words, for an
>>application to operate properly, the currently available QoS level
>>must somehow match the minimum QoS level that the application needs.
>>Thus, as far as an application is concerned, we can distinguish two
>>types of QoS
>>info:
>>
>>Type 1- The application's QoS needs (static information) (ex:
>>VideoConf Throughput:100kbps-Low Delay..) Type 2- The currently
>>available QoS (values are provided by the links, at L2, IP or TCP
>>level - dynamic information) that can be provided to the application.
>>
>>If I understood correctly, you provide a means for "type 2" QoS info
>>to be obtained by MIH users from the MIH, via MIH_Link_Parameter_Report.
>>
>>But if you don't have any input from your applications ("type 1" QoS
>>info), you won't be able to make them work optimally (you can just
>>maintain a pre-defined QoS level in your terminal, which can be
>>sub_optimal depending on the apps your run) I think it should be also
>>good to standardise the way applications communicate their QoS needs
>>("type 1" QoS info). One may argue that this can be directly
>>interfaced with a decision engine but in this case applications will
>>have to be compatible with each networks/terminal's decision engines.
>>So I think we should provide this feature into the MIH in the form of
>>two primitives:
>>
>>- One command (MIH_Configure_QoS.req/resp): for application to inform
>>the MIH of their QoS needs.
>>- One event (MIH_Configure_QoS.ind): for MIH users (such as decision
>>engines) to be notified of a new application's QoS need
>>
>>Here is a scenario that uses these primitives and yours:
>>(Note: MIH Users/MIH exchanges can be local or remote - MIH/Link Layer
>>exchanges are local - some required MIH messages exchanges are not shown):
>>
>>A- First step: QoS needs configuration
>>
>>APP Decision Engine
>>| ^
>>| |
>>|1/3)MIH_Configure_QoS.request/response
|2)MIH_Configure_QoS.indication
>>| |
>>v |
>>MIH --------------------------------------------
>>
>>
>>
>>In this step, the application configures the QoS level, according what
>>it is needed to function properly.
>>Multiple QoS parameters can be specified and there can be multiple
>>values for one QoS parameter, such as (Minimum, Average, Maximum).
>>Two new primitives are required: MIH_Configure_QoS in the form of a
>>command (1 and
>>3) and in the form of an event (2)
>>-> The MIH user ID (or application ID) must be embeded in the
>>MIH_Configure_QoS primitive.
>>
>>
>>B- Second Step: Threshold configuration
>>
>>
>>Decision Engine
>>|
>>|
>>|4/7)MIH_COnfigure_Threshold.request/response
>>|
>>v
>>MIH
>>|
>>|
>>|5/6)Link_Configure_THreshold.request/response
>>|
>>v
>>LLs
>>
>>If needed the Decision Engine can (re)configure thresholds for
>>different QoS parameters.
>>
>>
>>C- Third step: QoS parameter reports
>>
>>APP Decision Engine
>>^ ^
>>| |
>>|9)MIH_Link_PArameter_Report |9')MIH_Link_PArameter_Report
>>| |
>>MIH --------------------------------
>>^
>>|
>>|8)Link_Parameter_Report
>>|
>>LLs !!!Threshold crossed!!!
>>
>>In this step, a threshold is crossed for a particular parameter.4) The
>>Link_Parameter_Report is sent to the MIH which generates a
>>MIH_Link_Parameter report towards the Decision Engine (and possibly
>>the application itself).
>>
>>
>>D - Fourth Step: Handover
>>
>>
>>APP Decision Engine !!!!HO Required for
terminal A
>>^
>>| |
>>|13')MIH_Link_HAndover_Complete.ind |10/13)
MIH_Switch.request/response
>>| |
>>MIH <-------------------------------------
>>|
>>|11/12)Link_Switch.request/response
>>|
>>v
>>LLs
>>
>>In this step, if the Decision Engine decides an HO is needed for
>>terminal A, it sends a MIH_Switch.request to the MIH which trigger the
>>actual HO. Upon success, the Decision Engine (and possibly the
>>application) is notified.
>>The application can keep on operating at an optimal QoS level.
>>
>>--
>>
>>This could apply both to terminal based and network based framework.
>>New parameters may have to be specified for the primitives used in
>>this scenario.
>>
>>I hope this is clear enough!
>>
>>My wish is to be able to come up with an optimal QoS framework
>>together, if you like the ideas I presented above and if it somehow
>>shares your representation of the problem.
>>
>>Comments are welcome.
>>
>>
>>Regards,
>>
>>Mathieu
>>
>>
>>-----Message d'origine-----
>>De : Reijo Salminen [mailto:reijo.salminen@seesta.com]
>>Envoyé : jeudi 23 février 2006 09:40
>>À : zze-Seamless PERESSE M ext RD-RESA-REN; 'Olvera-Hernandez,
>>Ulises'; STDS-802-21@LISTSERV.IEEE.ORG Objet : RE: [802.21] Providing
>>QoS through current link layer primitives
>>
>>Hi, Mat
>>
>>It seems that the reflector has been down, so I send once more my 2
>>cents on this, maybe also Nada has some comments since she has been
>>the author of most of the slides in the submission.
>>
>>The main point is to make the QoS information available for the MIH
>>users, and then use the same lexicon that is used in ITU-T 1540/1541
>>and IETF NSIS, with lexicon I mean the parameters and their
>>interpretation. If the group has a possibility to get acquainted with
>>the referred documents/WG material (NSIS under URL
>>http://www.ietf.org/html.charters/nsis-charter.html), it would help in
>>understanding why the number of parameters should be kept as low as
>>possible, but still covering most of the predictable user application
>>requirements.
>>
>>Then another thing is what the users will be doing with the information.
>>This is outside the scope of 802.21, but since we anyway need to have
>>some visions what the possible scenarios could be, and what you have
>>asked, we could do some brainstorming on that.
>>
>>One probable user of the information is the functionality that is
>>involved with the interworking towards the core network, say for
>>example using NSIS signaling. In that case the 802.21 could maybe seen
>>as a network segment that is at least partially beyond the UNI
>>interface, where the scope of
>>ITU-T1540/41 and NSIS ends, if you look at the Figure1/1541 in the
>>submission. In this example then the NSIS QoS signaling, with the
>>desired/available/reserved/minimum QoS levels could be extended
>>towards the access, thus we could have the possibility to introduce
>>end-to-end QoS in the system, if we want.
>>
>>Another probable user is the decision making engine, which you mentioned.
>>But as we have in several occasions in 802.21 concluded, this is
>>outside the scope, as is the policies involved.
>>
>>Engineers working with the Admission Control functionality, might be
>>interested in using the possibilities of the proposed approach.
>>
>>By collecting statistics of the experienced QoS in the access
>>networks, could give a simple but reliable measure how mature the
>>access network is, I mean how well the network planning engineers have
>>done their challenging task on putting the AP:s/BS:es on correct
>>places and densely enough, as well as how well the admission control
>>is doing it's part. This information could be useful when making
>>decisions on the target access networks in the vertical handover -
>>this of course with cooperation of the information services functionality.
>>
>>There could be several other possible users of the information, the
>>application adaptation to the situation is one possible scenario, and
>>several others may emerge once the mechanism is available.
>>
>>I hope this helps in starting this interesting discussion, I hope we
>>can continue on this in the reflector and in the Denver meeting.
>>
>>BR, Reijo
>>
>>
>>
>>-----Original Message-----
>>From: stds-802-21@LISTSERV.IEEE.ORG
>>[mailto:stds-802-21@LISTSERV.IEEE.ORG]
>>On Behalf Of zze-Seamless PERESSE M ext RD-RESA-REN
>>Sent: 22. helmikuuta 2006 15:42
>>To: Olvera-Hernandez, Ulises; STDS-802-21@LISTSERV.IEEE.ORG
>>Subject: RE: [802.21] Providing QoS through current link layer
>>primitives
>>
>>Hi Ulises,
>>
>>I have read your document and I think this is a really good initiative.
>>
>>I have some questions:
>>
>>- do you have a scenario about how an application could use the "QoS
>>services" provided by the MIH ?
>>
>>If I understood correctly, the application can be informed about the
>>QoS parameters provided by the lower layers.
>>But what is the application going to do after getting this information ?
>>
>>What I can think of is:
>>
>>- Adapt itself to the new available QoS (for example, for a videoconf
>>app, if higher throughput is available the video resolution can be
raised).
>>- Ask for a handover when the available QoS level is not sufficient
>>anymore (using an existing MIH primitive ? Or a new one ? Or by
>>communicating with a decision engine which will then communicate with
>>the MIH ?)
>>
>>-> The QoS reports will pertain to the serving link or to other
>>-> available
>>links as well ?
>>
>>
>>Thanks,
>>
>>Mathieu.
>>
>>-----Message d'origine-----
>>De : Olvera-Hernandez, Ulises
>>[mailto:Ulises.Olvera-Hernandez@INTERDIGITAL.COM]
>>Envoyé : mercredi 22 février 2006 13:27 À :
>>STDS-802-21@listserv.ieee.org Objet : Re: [802.21] Providing QoS
>>through current link layer primitives
>>
>>Albert,
>>
>>There are new efforts within the 802.21 group to define a set of QoS
>>parameters that could be used by Mobility Management application and
>>Higher Layer entities to determine the QoS characteristics of the
>>underlying link.
>>Although this work has not yet been agreed or sanctioned by the group
>>there is already a contribution for the coming IEEE 802.21 March
>>meeting that provides a recommendation as to how this can be done.
>>This is publicly available at:
>>
>>http://grouper.ieee.org/groups/802/21/
>>
>>The contribution is stored onto the March 2006 folder, under the
>>following
>>name: 21-06-0493-02-0000-Threshold_Parameters_Survey.ppt
>>
>>Comments are appreciated.
>>
>>Ulises
>>
>>
>>-----Original Message-----
>>From: Soohong Daniel Park [mailto:soohong.park@SAMSUNG.COM]
>>Sent: Wednesday, February 22, 2006 4:52 AM
>>To: STDS-802-21@listserv.ieee.org
>>Subject: Re: [802.21] Providing QoS through current link layer
>>primitives
>>
>>QoS seems interesting and important issue in terms of link selectio
>>and change of 21 mobile node. Perhaps, you are saying more parameters
>>should be newly defined into this spec. than this. Right ? If yes,
>>which parameters are in your mind ?
>>
>>Daniel (Soohong Daniel Park)
>>Mobile Convergence Laboratory, SAMSUNG Electronics.
>>
>>----- Original Message -----
>>From: "Albert Vidal" <Albert.Vidal@NETLAB.NEC.DE>
>>To: <STDS-802-21@LISTSERV.IEEE.ORG>
>>Sent: Tuesday, February 21, 2006 1:55 AM
>>Subject: [802.21] Providing QoS through current link layer primitives
>>
>>
>>
>>
>>>Hi all,
>>>
>>>The current version of the draft specifies two primitives to report
>>>current link quality parameters:
>>>
>>>- Link_Parameters_Change
>>>- MIH_Link_Parameters_Report
>>>
>>>These two primitives could be valuable in order to maintain a certain
>>>QoS with the current PoA (Point of Attachment), as well as to
>>>
>>>
>>guarantee
>>
>>
>>>that the next potential PoA after a handover will be able offer the
>>>minimum QoS required.
>>>
>>>The text offers four example parameters to indicate the link quality:
>>>Link Speed, Link Bit Error Rate, Link Frame Loss Rate before
>>>retransmission and Link Received Signal Strength. Nevertheless, more
>>>parameters will be needed to guarantee the QoS, for instance to
>>>
>>>
>>address
>>
>>
>>>load balancing issues among different PoAs of the same network or to
>>>avoid a handover decision towards a congested PoA. (As an example,
>>>see some work in progress related to network initiated handovers in
>>>the framework of the European project Daidalos:
>>>
>>>
>>>
>>http://www.ietf.org/internet-drafts/draft-melia-mobopts-niho-ps-00.txt).
>>
>>
>>>How is this aspect of the text expected to be solved? Will the list
>>>of link layer parameters be left open, or on the contrary, will it be
>>>closed to a certain number of parameters?
>>>
>>>
>>>Best regards,
>>>Albert
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
--
Nada Golmie, Ph.D.
Manager, High Speed Network Technologies Group National Institute of
Standards and Technology 100 Bureau Dr. Stop 8920 Gaithersburg, MD 20899
Email: nada@nist.gov
Phone: (301) 975-4190
Fax: (301) 590-0932
Web: http://w3.antd.nist.gov