Re: [tsvwg] Draft TSVWG Yokohama minutes

[<[e-mail]>]

Hi Tim,

thanks for information - GSMA IR.34 was one of the motivations for my work on DiffServ intercon. 

There's one point I like about GSMA IR.34, that is signaling marked AF31. I'm aware that this isn't in line with RFC4594, but let's discuss that in a RFC4594 thread.

I dislike many aspects of GSMA IR.34. To get an additional view on RFC 7561, some information on the of mapping GSMA IR.34. Their QoS class "Interactive" GSMA IR.34 is specified in a broken way (my take). Interactive is defined as:
AF31, AF32, AF21, AF11. First two PHBs ordered by loss precedence and AF3, AF2 and AF1 by queuing priority. But taken as a single class "Interactive". RFC 7561 ignores this single class concept and assigns three Ethernet priorities. I prefer to maintain a view on Interactive as a single class on IP level (and I ignore the queuing priorities). As I basically think, that GSMA IR.34 is broken on the specification of their Interactive class, I'm not going to discuss the best mapping. I also think you better ignore any suggested mappings. 

GSMA IR.34 is informative, afaik.

Regards,

Ruediger


-----Ursprüngliche Nachricht-----
Von: tsvwg [mailto:[e-mail]] Im Auftrag von Tim Szigeti (szigeti)
Gesendet: Montag, 7. März 2016 12:28
An: Black, David; [e-mail]
Betreff: Re: [tsvwg] Draft TSVWG Yokohama minutes

Hi David and Team,

When discussing draft-szigeti-tsvwg-ieee-802-11, the comment below was made:

---

b) The DSCP mapping to/from 802.11 that was driven by compatibility with mobile
	networks is in Section 4.2 of RFC 7561:
	https://tools.ietf.org/html/rfc7561#section-4.2

---

RFC 7561 (which falls under tsv charter, yet was passed outside of it) makes a set of recommendations for DSCP-to-UP mappings that are not based on IETF RFCs, but rather based on third-party recommendations (i.e. the GSMA).

The reason why (several) mappings from draft-szigeti-tsvwg-ieee-802-11-00 are different from RFC 7561 is because the context and intents of these documents are significantly different:
. RFC 7561 seeks to map recommendations from a GSMA best practices document to IEEE 802.11 . Our draft seeks to reconcile IETF RFC 4594 with IEEE 802.11

Furthermore, many of the recommendations made in the GSMA "Guidelines for IPX Provider networks" document (and as reflected in Table 3 in RFC 7561) are in *direct contradiction* to recommendations made in IETF RFC 4594, including:

. EF marking for conversational video (RFC 4594 recommends EF marking for voice-telephony) . EF marking for real-time gaming (RFC 4594 recommends CS4 marking for gaming) . AF41 marking for  buffered streaming (RFC 4594 recommends AF31 marking for streaming media) . AF31 marking for signaling (RFC 4594 recommends CS5 marking for signaling) . AF21 marking for interactive gaming (RFC 4594 recommends CS4 marking for gaming) . AF11 marking for web access  (RFC 4594 recommends AF11 marking for high-throughput data; whereas web access is typically low-latency data, marked AF21) . DF marking for email  (RFC 4594 recommends AF11 marking for high-throughput data applications, such as file-transfers and email)


As such, it should not be surprising that some recommendations in RFC 7561 to not align with our draft. Our draft views RFC 4594 as the IETF's recommendations for DSCP marking, and does not rely on some third-party's recommendations on how DSCP should be marked.

As such, it is the view of the authors of draft-szigeti-tsvwg-ieee-802-11 that we do not have to justify why we have chosen to align with IETF recommendations (as this should be self-evident) and not third-party (GSMA) recommendations. If a reconciliation needs to be made somewhere, it should be by the authors of RFC 7561 to explain why they have chosen to disregard IETF recommendations and use GSMA recommendations instead.

We're asking for draft-szigeti-tsvwg-ieee-802-11 to be called for adoption. 

Thanks in advance.

-tim


-----Original Message-----
From: tsvwg [mailto:[e-mail]] On Behalf Of Black, David
Sent: Saturday, November 14, 2015 10:59 AM
To: [e-mail]
Subject: [tsvwg] Draft TSVWG Yokohama minutes

See: https://www.ietf.org/proceedings/94/minutes/minutes-94-tsvwg

Please send corrections, comments and/or changes to the chairs (and to the list if appropriate).

Many thanks to Pasi Sarolahti and Aaron Falk for taking notes.

I've added a couple of additional elaborations to the minutes that I'll repeat here:

a) WRT to existing magic numbers for demux within the UDP encapsulation
	used by Web RTC, see draft-ietf-avtcore-rfc5764-mux-fixes, as that
	draft corrects some serious problems in RFC 5764:
	http://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/

b) The DSCP mapping to/from 802.11 that was driven by compatibility with mobile
	networks is in Section 4.2 of RFC 7561:
	https://tools.ietf.org/html/rfc7561#section-4.2


Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------