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

[John Kaippallimalil <[e-mail]>]

Hi,
We just posted a new revision of the draft-ietf-netext-pmip-qos-wifi with Sri's comments addressed:

-          Description of LMA initiated QoS reservation with IEEE 802.11aa

-          MN and session parameter descriptions, security text and other revisions for references, etc.


The draft is ready for WGLC in our opinion.

Regards,
John

Link to new version:

The IETF datatracker status page for this draft is:

https://datatracker.ietf.org/doc/draft-ietf-netext-pmip-qos-wifi/



There's also a htmlized version available at:

http://tools.ietf.org/html/draft-ietf-netext-pmip-qos-wifi-02



From: netext [mailto:[e-mail]] On Behalf Of Sri Gundavelli (sgundave)
Sent: Tuesday, September 16, 2014 12:47 AM
To: [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.

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

> 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 ?

> Section 1.2: TSPEC
Add a reference to TSPEC

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

> PMIPV6
Should be PMIPv6

> Handovers ?
I did not see much text on what happens to the QoS states after a MN's inter-MAG handovers.

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

> 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 ?

> 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

> 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.


> 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