Re: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01

["Sri Gundavelli (sgundave)" <[e-mail]>]

Hi John,

> With regard to the major comment: - for QoS setup from AP to STA,  we cannot convey  the relevant flow/stream in 802.11aa (it would need further standardization in IEEE).

May be a recommendation on the needed changes will help.


Regards
Sri

From: John Kaippallimalil <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 16, 2014 11:34 AM
To: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "Rajesh Pazhyannur (rpazhyan)" <[e-mail]<mailto:[e-mail]>>, Parviz Yegani <[e-mail]<mailto:[e-mail]>>
Subject: RE: Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01

Hi Sri,
Thank you for a very thorough review and comments.

With regard to the major comment: - for QoS setup from AP to STA,  we cannot convey  the relevant flow/stream in 802.11aa (it would need further standardization in IEEE).
Rajesh and I can discuss with you some simple text to address this comment.

The other comments are relatively straightforward (see some notes inline below).

In the next revision, we will address all these comments.

Best Regards,
John



From: netext [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, September 16, 2014 12:47 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [netext] Review Comments on I-D: draft-ietf-netext-pmip-qos-wifi-01

Hi Authors:

I've reviewed the -01 version of Wi-Fi QoS document. Its is well written. Its in a good shape. Few comments below.



Major Comment:

> Section 3: "However, there are no standards defined way for the AP to initiate a QoS service request to the MN."

I'm bit disappointed to see the removal of the support for network initiated QoS set-up.  John, Rajesh and myself had several offline discussions on this few months back; Here is my comment from earlier discussions. I'm not asking the Authors to add the support for network-initiated dynamic QoS, but I thought it will be good to get some feedback from others.

"I do not understand the 802.11 guys thinking on this entire StreamId business. When I first looked at it this, I thought this is just a identifier used in Application signaling. But, when this is tied to .1Q, even the basic semantics on the StreamId length or how its used in the network is not clear to me. Their view that the tag is global and can be enforced in the entire network seems bit broken. But, that spec is not my area of expertise and so may be I missing the real intent here.

However, when I look at this from PMIP QoS point of view and with the goal of realizing end to end QoS, the QoS enforcement  in this context is on the MAG/AP. QoS enforcement on the rest of the network (MAG to LMA) is PMIP issue. If that is the baseline requirement, my point is what stops the UE or the MAG implementation to ignore the StreamId completely ? MAG and UE represent the two end points of the air interface and they both have the TFT.  So, this entire streamId business is total non-sense, specially the key protocols such as SIP have no mapping. So, even if there is public OUI allocation, I fail to understand how it fits in the overall scheme of things. So, my initial suggestion was to workaround the StreamId and make the spec work.
"



Additional Comments:

> Introduction: "STA"
Please add a reference or explanation on "STA" term - Station; In general, please add references/explanations to all Wi-Fi terminology.
OK, will revise

> "The Mean Data Rate does not include the MAC and PHY overheads [WMM1.2.0]"
 Some explanation can help.
Will add explanation

> However, this document does not exclude
   various deployments including those where AP and WLC are separate
   nodes, or the MAG control and data planes are separate."

Should there any guidance on how the QoS parameters are negotiated/exchanged between AP and WLC in the split mode ?
Did not want to add specifics since this is implementation specific.

> Section 1.2: TSPEC
Add a reference to TSPEC
OK, will revise

> GBR, AMBR Terminology
You may want to add a reference to RFC 7222 Terminology section. There is explanation for GBR, AMBR and other parameters
OK, will revise.

> PMIPV6
Should be PMIPv6
OK.

> Handovers ?
I did not see much text on what happens to the QoS states after a MN's inter-MAG handovers.
We refer to RFC 7222 for the overall session handling.
In

> Section 4.1
Please use "Traffic Class" in the table, instead of "DSCP"
OK.

> Error Code Mapping
RFC7222 defines couple of error codes. Its not clear how those error codes map to the Cause Codes in ADDTS Response. I saw just one Cause Code. Is that all ?
Will revise to add other error codes.

> Scope: Per-MN, Per-Session,
No discussion on the scope. Its unclear how the Per-Session, Per-MN attributes map to different Wi-Fi QoS elements
The connection parameters – 4.1 shows the mapping per session and MN attributes.
Can revise text in introduction that refers to per MN and per session to give the context.

> Security Considerations
You may want to add some text on how WLAN security architecture can protect the integrity of the QoS signaling messages on the air interface. The current text may not be sufficient.
Will review.


> References
Informative Reference to RFC 5213 and 5844 as the PBU/PBA messages are used in call flows
Add a reference to UPN/UPA spec (RFC7077) as its used in call flows
OK.