About draft-polk-tsvwg-rfc4594-update-00.txt

James,

After returning home from IETF 83, I have been reading your draft. I find it
interesting to standardize the service classes. Otherwise, if each one
classifies each traffic according to different criteria, Diffserv becomes
less useful.

Regarding "Real-time interactive" service class, which refers to online
gaming (my main research field), I find it really interesting: online games
are at least as real-time as VoIP is. In most cases, the gamers are a very
difficult people to deal with. If the latency is high, they leave and never
return (this statement is not mine, it can be corroborated in the references
I put below). This has been studied by many research groups, with empirical
tests using real gamers and adding delay, jitter, packet loss.

Other question: in the draft it is said that online games use RTP/UDP
streams. This can be a little confusing. In fact, the vast majority of
online games do not use RTP, but bare UDP or even TCP. In
http://www.cn.uni-duesseldorf.de/publications... the
authors proposed the use of an adaptation of RTP in order to manage gaming
traffic. But as far as I know, this approach is not used by commercial
games.

A typical classification of today's games is:

-          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
Duty: They use UDP

-          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
World of Warcraft: They normally use TCP, even though some of them use UDP

-          RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or
UDP

-          Sports games: Since there is a big variety, they have not been
deeply studied in the literature

Some research papers supporting this classification, and also the real-time
requirements of the games:

First Person Shooters

-          A survey of traffic models for 17 First Person Shooters can be
found here. All of them use UDP
http://www.discover.uottawa.ca/publications/f...

-          In this paper from my research group, 8 FPS games were analyzed
in order to compress and multiplex their traffic. Figure 5 shows their
histograms (inter-packet time and packet size). It can be seen that they
generate real-time flows, with characteristics very similar to VoIP (packets
of 60-80 bytes every 15-40 ms):
http://diec.unizar.es/~jsaldana/personal/comm...

-          Another paper about FPS using UDP. Section V presents some
interesting conclusions about routing infrastructure.
http://www.thefengs.com/wuchang/work/cstrike/...

-          In this paper the network factors annoying the gamers are
analyzed. There are also some calculations of the MOS. Above 150 ms the
quality is bad (something similar to what happens with VoIP)
http://www.research.ibm.com/netgames2005/pape...

-          In this one, a MOS model for a FPS (Quake IV) is deployed. It is
only based on delay and jitter, since packet loss has vevy little influence
(for this concrete game). Delay above 140 ms produces MOS below 3
http://www.nas.ewi.tudelft.nl/publications/20...

-          In this paper, it is found that some FPS work properly even with
30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150
OWD) makes MOS go above 3
http://caia.swin.edu.au/pubs/ATNAC04/zander-a...

MMORPGs:

-          A traffic model for World of Warcraft:
http://publik.tuwien.ac.at/files/pub-et_12119...

-          This one presents a MOS for World of Warcraft. When added delay
is above 160ms, the MOS is roughly 3.:
http://publik.tuwien.ac.at/files/PubDat_17020...

Best regards,

Jose Saldana

Jose,

you raise an interesting point:

draft-polk-tsvwg-rfc4594-update suggests to standardise application to codepoint mapping as well as codepoint to class properties. You observe that some games are using TCP while others use UDP, which I think is a useful level of QoS requirement abstraction. There's no need to have like 25+ QoS (sub)classes, I think. But one class optimised to transport  "UDP" and one for "TCP" are agreeable.

The feedback that I had on carrier class QoS usage is that there's a point in standardising class properties, and certainly not to standardise application mappings to classes (recommending them may however be useful). My take would be to standardise four classes/properties (in brackets example usage):

a) for traffic which doesn't support re-transmits, requiring lowest delay and jitter, having limited volume and packet
   size, but being loss tolerant (example usage VoIP)
b) for any other traffic which doesn't support re-transmits (let's say traffic with real time like properties, but any
   packet size and possibly high volume, UDP transport, like IPTV)
c) for any other traffic which supports re-transmits (QoS traffic using TCP, like application signalling and network management traffic)
d) a default class, for any traffic supporting re-transmits (Best Effort) - this class may not be regarded as QoS (or as lowest CoS)

What I can tell ist that many carriers and standards on QoS support 3-4 classes, having properties as described above. It is useful to recommend codepoints matching to these classes. Standardising these codepoints requires agreement between those having deplyed them. Straightforward for a) EF and d) 000000, probably easy for c) being used to transport Network Management (CS 6). I'm not aware of common ground for anything else. My favourites are:

b) AF4 (GSMA supports this one, RFC4594 also)
c) AF3 (MEF and GSMA support this one)

Gaming from my point of view would then match to an AF3 or AF4 class, this may depend on the implemented application transport. Further details may be discussed.

Everything else could be reserved, but shouldn't be recommended. Carriers have deployed differing schemes on codepoints and classes. They need coding reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as well as in DSCP space if they should converge to a standardised codepoint/class scheme.

I object to any approach standardising a match of classes and applications with codepoints as a requirement and I also object to standards leaving no spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP precedence).

Bob Briscoe mentioned the difference between classes and queues and above properties can be mapped to queues. If end to end QoS is desired, the same class properties must be negotiated end to end. The lower the number of classes and codepoints being deployed, the higher the probability of getting end to end QoS. I don't support an approach requiring 8 three bit classes and 25 or more 6 bit classes and codepoints.

Regards,

Ruediger

Ruediger,

I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
after talking to James, I thought that the idea of standardizing the traffic
classification fits well with my proposal. I would like to know your opinion
about it, if possible.

The idea is to use tunnels in order to compress and multiplex real-time
traffic flows. Since these flows tend to use very small packets, they have
very bad efficiency. So perhaps tunnels could be used in order to group
these flows. The drawback is that they add small delays, i.e. the waiting
time in the multiplexer. So another use is to provide flexibility: if you
are a game provider, you may over provision your network in order to be able
to manage traffic peaks. But perhaps using this, you may be able to have a
smaller network, and use compression when necessary (rush hour, first days
after releasing a new game, etc). When traffic is small, you do not
multiplex, in order to reduce latency.

So if traffic classification is a standard, everyone in the way from the
origin to the destination will handle the traffic with the correct priority.

I attach a figure in order to clarify.

Thank you,

Jose

PS: In
http://community.virginmedia.com/t5/Fibre-opt...
craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
the history of the problems of World of Warcraft for Virgin Media users. The
problem was caused by a modification in the traffic, and the provider did
not notice about it, so it treated the packets as best-effort.

-----Mensaje original-----
De:   
Enviado el: jueves, 05 de abril de 2012 9:49
Para: 
CC: 
Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Jose,

you raise an interesting point:

draft-polk-tsvwg-rfc4594-update suggests to standardise application to
codepoint mapping as well as codepoint to class properties. You observe that
some games are using TCP while others use UDP, which I think is a useful
level of QoS requirement abstraction. There's no need to have like 25+ QoS
(sub)classes, I think. But one class optimised to transport  "UDP" and one
for "TCP" are agreeable.

The feedback that I had on carrier class QoS usage is that there's a point
in standardising class properties, and certainly not to standardise
application mappings to classes (recommending them may however be useful).
My take would be to standardise four classes/properties (in brackets example
usage):

a) for traffic which doesn't support re-transmits, requiring lowest delay
and jitter, having limited volume and packet
   size, but being loss tolerant (example usage VoIP)
b) for any other traffic which doesn't support re-transmits (let's say
traffic with real time like properties, but any
   packet size and possibly high volume, UDP transport, like IPTV)
c) for any other traffic which supports re-transmits (QoS traffic using TCP,
like application signalling and network management traffic)
d) a default class, for any traffic supporting re-transmits (Best Effort) -
this class may not be regarded as QoS (or as lowest CoS)

What I can tell ist that many carriers and standards on QoS support 3-4
classes, having properties as described above. It is useful to recommend
codepoints matching to these classes. Standardising these codepoints
requires agreement between those having deplyed them. Straightforward for a)
EF and d) 000000, probably easy for c) being used to transport Network
Management (CS 6). I'm not aware of common ground for anything else. My
favourites are:

b) AF4 (GSMA supports this one, RFC4594 also)
c) AF3 (MEF and GSMA support this one)

Gaming from my point of view would then match to an AF3 or AF4 class, this
may depend on the implemented application transport. Further details may be
discussed.

Everything else could be reserved, but shouldn't be recommended. Carriers
have deployed differing schemes on codepoints and classes. They need coding
reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
well as in DSCP space if they should converge to a standardised
codepoint/class scheme.

I object to any approach standardising a match of classes and applications
with codepoints as a requirement and I also object to standards leaving no
spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
precedence).

Bob Briscoe mentioned the difference between classes and queues and above
properties can be mapped to queues. If end to end QoS is desired, the same
class properties must be negotiated end to end. The lower the number of
classes and codepoints being deployed, the higher the probability of getting
end to end QoS. I don't support an approach requiring 8 three bit classes
and 25 or more 6 bit classes and codepoints.

Regards,

Ruediger

Jose,

regarding QoS, I'm happy to agree on 4 standard classes with properties as
mentioned in my last email. If there's consensus on some codepoints for them,
I'll support that.

If IETF recommends how and which applications to use these classes/codepoints,
that's again agreeable. I don't think, that by now requiring a specific
application to carry a specific DSCP makes sense, apart from few exceptions
(like VoIP payload, network management traffic or Best Effort traffic).
IETF needs consensus to do that.
Note that the number of AF classes and codepoints are troublesome. Too many
with too little explanation how to use them, nothing is aligned with user
demand. EF/VoIP payload and network management are examples how to proceed:
just specify what's required, no extras.


Then regarding tunnels and header compression
Yes, that's smart and there may be more use cases than gaming. I'm a backbone
engineer however and your proposal is rather application specific. What I
can do is ask some colleagues on their view. But there's no guarantee, that
they will respond.

Some initial thoughts:
To me a key point seems to be what can be reached at the bottleneck. There the
compression should save bandwidth with little cost and no negative
service impact. Any kind of shared access from which traffic is transmitted
to the same destination seems to be relevant. The application/tunnel awareness of
network elements may not be feasible, a network terminal at a UNI may be able to
handle that, or any service specific device in a network.

Regards,

Ruediger


-----Original Message-----
From: Jose Saldana 
Sent: Thursday, April 05, 2012 11:29 AM
To: Geib, Rüdiger
Cc: 
Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Ruediger,

I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
after talking to James, I thought that the idea of standardizing the traffic
classification fits well with my proposal. I would like to know your opinion
about it, if possible.

The idea is to use tunnels in order to compress and multiplex real-time
traffic flows. Since these flows tend to use very small packets, they have
very bad efficiency. So perhaps tunnels could be used in order to group
these flows. The drawback is that they add small delays, i.e. the waiting
time in the multiplexer. So another use is to provide flexibility: if you
are a game provider, you may over provision your network in order to be able
to manage traffic peaks. But perhaps using this, you may be able to have a
smaller network, and use compression when necessary (rush hour, first days
after releasing a new game, etc). When traffic is small, you do not
multiplex, in order to reduce latency.

So if traffic classification is a standard, everyone in the way from the
origin to the destination will handle the traffic with the correct priority.

I attach a figure in order to clarify.

Thank you,

Jose

PS: In
http://community.virginmedia.com/t5/Fibre-opt...
craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
the history of the problems of World of Warcraft for Virgin Media users. The
problem was caused by a modification in the traffic, and the provider did
not notice about it, so it treated the packets as best-effort.

-----Mensaje original-----
De:  
Enviado el: jueves, 05 de abril de 2012 9:49
Para: 
CC: 
Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Jose,

you raise an interesting point:

draft-polk-tsvwg-rfc4594-update suggests to standardise application to
codepoint mapping as well as codepoint to class properties. You observe that
some games are using TCP while others use UDP, which I think is a useful
level of QoS requirement abstraction. There's no need to have like 25+ QoS
(sub)classes, I think. But one class optimised to transport  "UDP" and one
for "TCP" are agreeable.

The feedback that I had on carrier class QoS usage is that there's a point
in standardising class properties, and certainly not to standardise
application mappings to classes (recommending them may however be useful).
My take would be to standardise four classes/properties (in brackets example
usage):

a) for traffic which doesn't support re-transmits, requiring lowest delay
and jitter, having limited volume and packet
   size, but being loss tolerant (example usage VoIP)
b) for any other traffic which doesn't support re-transmits (let's say
traffic with real time like properties, but any
   packet size and possibly high volume, UDP transport, like IPTV)
c) for any other traffic which supports re-transmits (QoS traffic using TCP,
like application signalling and network management traffic)
d) a default class, for any traffic supporting re-transmits (Best Effort) -
this class may not be regarded as QoS (or as lowest CoS)

What I can tell ist that many carriers and standards on QoS support 3-4
classes, having properties as described above. It is useful to recommend
codepoints matching to these classes. Standardising these codepoints
requires agreement between those having deplyed them. Straightforward for a)
EF and d) 000000, probably easy for c) being used to transport Network
Management (CS 6). I'm not aware of common ground for anything else. My
favourites are:

b) AF4 (GSMA supports this one, RFC4594 also)
c) AF3 (MEF and GSMA support this one)

Gaming from my point of view would then match to an AF3 or AF4 class, this
may depend on the implemented application transport. Further details may be
discussed.

Everything else could be reserved, but shouldn't be recommended. Carriers
have deployed differing schemes on codepoints and classes. They need coding
reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
well as in DSCP space if they should converge to a standardised
codepoint/class scheme.

I object to any approach standardising a match of classes and applications
with codepoints as a requirement and I also object to standards leaving no
spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
precedence).

Bob Briscoe mentioned the difference between classes and queues and above
properties can be mapped to queues. If end to end QoS is desired, the same
class properties must be negotiated end to end. The lower the number of
classes and codepoints being deployed, the higher the probability of getting
end to end QoS. I don't support an approach requiring 8 three bit classes
and 25 or more 6 bit classes and codepoints.

Regards,

Ruediger

I have been reading the two messages of Ruediger about Jame's draft. I will
try to make a "status of the question" and then a proposal. If something is
wrong, just tell me.

- We have the old 8 TOS bits of the IP header. Nowadays, two of them are
ECN, and six of them are the DSCP field. So the problem is how to use these
6 bits (64 possible values)
- Network control is 11xxxx, so this uses 16 values
	-11xx11 are defined in RFC 2474, and remain as only experimentally
assignable/useable (this uses 4 of these 16 values)
- This leaves 48 values
- Best effort is 000000
- The draft of James proposes 14 values for the DSCP field, which correspond
to service classes, mapped to application categories.

But Ruediger says that, in his opinion, more than 4 classes are not useful,
according to current implementations.

We can ask ourselves: which are  the key parameters that define how packets
have to be managed in a router? I think that they are:

1) "Real-time-ness": The tolerated delay of the service. The jitter can be
roughly included in this parameter.
2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
since they retransmit packets. And some UDP services are also tolerant to
loss (VoIP, some games, etc)

In my opinion, the "real-time-ness" is the key: it distinguishes very
similar services: e.g. a video conference is different from a broadcast,
since the latter permits delays of some seconds, whereas the first has to be
interactive.

So one possible solution could be:

- Using the first two bits in order to define 4 classes, taking into account
the existing implementations. They can be the 4 classes of Fig. 1 of James'
draft, or the ones proposed by Ruediger.
	00xxxx	best effort
	01xxxx data
	10xxxx media oriented
	11xxxx control

- With the other 4 bits, something should be done. My proposal:
	- If the third bit is "1", then the other three bits include a value
defining the "real-time-ness" of the flow. So we have 8 levels of
real-time-ness. Some examples:
		- 10-1-111 would be a  media-oriented (10) and very
real-time flow, as VoIP or a game
		- 10-0-xxx would be a media-oriented flow for which the
real-time-ness is not defined
		- 10-1-010 could be a media-oriented flow with medium delay
requirements, as multimedia conferencing
		- 10-1-000 would be a media-oriented flow with no very hard
delay requirements, as multimedia streaming
		- 00-xxxx would be best-effort
		-01-1-111 would be very low-latency data
		-01-1-000 would be low-priority data

One advantage of this is that some routers may only take into account the
first two bits, and others would use all of them.

The new RFC could suggest or define different values of real-time-ness for
each application. So the applications should be ordered depending of the
maximum tolerated delay.

Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
Regards,

Jose

-----Mensaje original-----
De:   
Enviado el: jueves, 05 de abril de 2012 12:23
Para: 
CC: 
Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Jose,

regarding QoS, I'm happy to agree on 4 standard classes with properties as
mentioned in my last email. If there's consensus on some codepoints for
them, I'll support that.

If IETF recommends how and which applications to use these
classes/codepoints, that's again agreeable. I don't think, that by now
requiring a specific application to carry a specific DSCP makes sense, apart
from few exceptions (like VoIP payload, network management traffic or Best
Effort traffic).
IETF needs consensus to do that.
Note that the number of AF classes and codepoints are troublesome. Too many
with too little explanation how to use them, nothing is aligned with user
demand. EF/VoIP payload and network management are examples how to proceed:
just specify what's required, no extras.


Then regarding tunnels and header compression Yes, that's smart and there
may be more use cases than gaming. I'm a backbone engineer however and your
proposal is rather application specific. What I can do is ask some
colleagues on their view. But there's no guarantee, that they will respond.

Some initial thoughts:
To me a key point seems to be what can be reached at the bottleneck. There
the compression should save bandwidth with little cost and no negative
service impact. Any kind of shared access from which traffic is transmitted
to the same destination seems to be relevant. The application/tunnel
awareness of network elements may not be feasible, a network terminal at a
UNI may be able to handle that, or any service specific device in a network.

Regards,

Ruediger


-----Original Message-----
From: Jose Saldana 
Sent: Thursday, April 05, 2012 11:29 AM
To: Geib, Rüdiger
Cc: 
Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Ruediger,

I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
after talking to James, I thought that the idea of standardizing the traffic
classification fits well with my proposal. I would like to know your opinion
about it, if possible.

The idea is to use tunnels in order to compress and multiplex real-time
traffic flows. Since these flows tend to use very small packets, they have
very bad efficiency. So perhaps tunnels could be used in order to group
these flows. The drawback is that they add small delays, i.e. the waiting
time in the multiplexer. So another use is to provide flexibility: if you
are a game provider, you may over provision your network in order to be able
to manage traffic peaks. But perhaps using this, you may be able to have a
smaller network, and use compression when necessary (rush hour, first days
after releasing a new game, etc). When traffic is small, you do not
multiplex, in order to reduce latency.

So if traffic classification is a standard, everyone in the way from the
origin to the destination will handle the traffic with the correct priority.

I attach a figure in order to clarify.

Thank you,

Jose

PS: In
http://community.virginmedia.com/t5/Fibre-opt...
craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
the history of the problems of World of Warcraft for Virgin Media users. The
problem was caused by a modification in the traffic, and the provider did
not notice about it, so it treated the packets as best-effort.

-----Mensaje original-----
De:   Enviado el:
jueves, 05 de abril de 2012 9:49
Para: 
CC: 
Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

Jose,

you raise an interesting point:

draft-polk-tsvwg-rfc4594-update suggests to standardise application to
codepoint mapping as well as codepoint to class properties. You observe that
some games are using TCP while others use UDP, which I think is a useful
level of QoS requirement abstraction. There's no need to have like 25+ QoS
(sub)classes, I think. But one class optimised to transport  "UDP" and one
for "TCP" are agreeable.

The feedback that I had on carrier class QoS usage is that there's a point
in standardising class properties, and certainly not to standardise
application mappings to classes (recommending them may however be useful).
My take would be to standardise four classes/properties (in brackets example
usage):

a) for traffic which doesn't support re-transmits, requiring lowest delay
and jitter, having limited volume and packet
   size, but being loss tolerant (example usage VoIP)
b) for any other traffic which doesn't support re-transmits (let's say
traffic with real time like properties, but any
   packet size and possibly high volume, UDP transport, like IPTV)
c) for any other traffic which supports re-transmits (QoS traffic using TCP,
like application signalling and network management traffic)
d) a default class, for any traffic supporting re-transmits (Best Effort) -
this class may not be regarded as QoS (or as lowest CoS)

What I can tell ist that many carriers and standards on QoS support 3-4
classes, having properties as described above. It is useful to recommend
codepoints matching to these classes. Standardising these codepoints
requires agreement between those having deplyed them. Straightforward for a)
EF and d) 000000, probably easy for c) being used to transport Network
Management (CS 6). I'm not aware of common ground for anything else. My
favourites are:

b) AF4 (GSMA supports this one, RFC4594 also)
c) AF3 (MEF and GSMA support this one)

Gaming from my point of view would then match to an AF3 or AF4 class, this
may depend on the implemented application transport. Further details may be
discussed.

Everything else could be reserved, but shouldn't be recommended. Carriers
have deployed differing schemes on codepoints and classes. They need coding
reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
well as in DSCP space if they should converge to a standardised
codepoint/class scheme.

I object to any approach standardising a match of classes and applications
with codepoints as a requirement and I also object to standards leaving no
spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
precedence).

Bob Briscoe mentioned the difference between classes and queues and above
properties can be mapped to queues. If end to end QoS is desired, the same
class properties must be negotiated end to end. The lower the number of
classes and codepoints being deployed, the higher the probability of getting
end to end QoS. I don't support an approach requiring 8 three bit classes
and 25 or more 6 bit classes and codepoints.

Regards,

Ruediger

Jose

Thanks for giving this effort. SPs usually use 
MPLS, which has 3 bits (8 values) of 
differentiation. Thus, for SPs, this is the goal 
-> to be 8 values or less. I don't expect too 
many, if any, SPs to want to do 8 different 
values per customer, so I understand where 
Ruediger is coming from. At the same time, there 
are many networks that want far more than 8 
values for use, so SP desires to box everyone 
into only their way of managing the world is not 
satisfactory to these other networks.  Thus, the 
draft discusses aggregating several service 
classes into a since value when traveling over SP 
networks. The draft says in many places that not 
all service classes are needed, and in fact that 
few likely would be used across SP networks. What 
the draft *didn't* make clear is saying this idea 
in a concise part (i.e., its own section) of the 
draft (instead, it was spread over the whole 
draft). I said in the meeting that was an error 
on my part. I also said at the meeting the next 
version of the draft will have this concept in a 
nice, concise standalone section that (hopefully) 
will make this idea more apparent.

I plan to get the next version written well before Vancouver, for WG review.

JamesAt 07:03 AM 4/7/2012, Jose Saldana wrote:
>I have been reading the two messages of Ruediger about Jame's draft. I will
>try to make a "status of the question" and then a proposal. If something is
>wrong, just tell me.
>
>- We have the old 8 TOS bits of the IP header. Nowadays, two of them are
>ECN, and six of them are the DSCP field. So the problem is how to use these
>6 bits (64 possible values)
>- Network control is 11xxxx, so this uses 16 values
>         -11xx11 are defined in RFC 2474, and remain as only experimentally
>assignable/useable (this uses 4 of these 16 values)
>- This leaves 48 values
>- Best effort is 000000
>- The draft of James proposes 14 values for the DSCP field, which correspond
>to service classes, mapped to application categories.
>
>But Ruediger says that, in his opinion, more than 4 classes are not useful,
>according to current implementations.
>
>We can ask ourselves: which are  the key parameters that define how packets
>have to be managed in a router? I think that they are:
>
>1) "Real-time-ness": The tolerated delay of the service. The jitter can be
>roughly included in this parameter.
>2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
>since they retransmit packets. And some UDP services are also tolerant to
>loss (VoIP, some games, etc)
>
>In my opinion, the "real-time-ness" is the key: it distinguishes very
>similar services: e.g. a video conference is different from a broadcast,
>since the latter permits delays of some seconds, whereas the first has to be
>interactive.
>
>So one possible solution could be:
>
>- Using the first two bits in order to define 4 classes, taking into account
>the existing implementations. They can be the 4 classes of Fig. 1 of James'
>draft, or the ones proposed by Ruediger.
>         00xxxx  best effort
>         01xxxx data
>         10xxxx media oriented
>         11xxxx control
>
>- With the other 4 bits, something should be done. My proposal:
>         - If the third bit is "1", then the other three bits include a value
>defining the "real-time-ness" of the flow. So we have 8 levels of
>real-time-ness. Some examples:
>                 - 10-1-111 would be a  media-oriented (10) and very
>real-time flow, as VoIP or a game
>                 - 10-0-xxx would be a media-oriented flow for which the
>real-time-ness is not defined
>                 - 10-1-010 could be a media-oriented flow with medium delay
>requirements, as multimedia conferencing
>                 - 10-1-000 would be a media-oriented flow with no very hard
>delay requirements, as multimedia streaming
>                 - 00-xxxx would be best-effort
>                 -01-1-111 would be very low-latency data
>                 -01-1-000 would be low-priority data
>
>One advantage of this is that some routers may only take into account the
>first two bits, and others would use all of them.
>
>The new RFC could suggest or define different values of real-time-ness for
>each application. So the applications should be ordered depending of the
>maximum tolerated delay.
>
>Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
>Regards,
>
>Jose
>
>-----Mensaje original-----
>De:  
>Enviado el: jueves, 05 de abril de 2012 12:23
>Para: 
>CC: 
>Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>Jose,
>
>regarding QoS, I'm happy to agree on 4 standard classes with properties as
>mentioned in my last email. If there's consensus on some codepoints for
>them, I'll support that.
>
>If IETF recommends how and which applications to use these
>classes/codepoints, that's again agreeable. I don't think, that by now
>requiring a specific application to carry a specific DSCP makes sense, apart
>from few exceptions (like VoIP payload, network management traffic or Best
>Effort traffic).
>IETF needs consensus to do that.
>Note that the number of AF classes and codepoints are troublesome. Too many
>with too little explanation how to use them, nothing is aligned with user
>demand. EF/VoIP payload and network management are examples how to proceed:
>just specify what's required, no extras.
>
>
>Then regarding tunnels and header compression Yes, that's smart and there
>may be more use cases than gaming. I'm a backbone engineer however and your
>proposal is rather application specific. What I can do is ask some
>colleagues on their view. But there's no guarantee, that they will respond.
>
>Some initial thoughts:
>To me a key point seems to be what can be reached at the bottleneck. There
>the compression should save bandwidth with little cost and no negative
>service impact. Any kind of shared access from which traffic is transmitted
>to the same destination seems to be relevant. The application/tunnel
>awareness of network elements may not be feasible, a network terminal at a
>UNI may be able to handle that, or any service specific device in a network.
>
>Regards,
>
>Ruediger
>
>
>-----Original Message-----
>From: Jose Saldana 
>Sent: Thursday, April 05, 2012 11:29 AM
>To: Geib, Rüdiger
>Cc: 
>Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>Ruediger,
>
>I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
>know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
>after talking to James, I thought that the idea of standardizing the traffic
>classification fits well with my proposal. I would like to know your opinion
>about it, if possible.
>
>The idea is to use tunnels in order to compress and multiplex real-time
>traffic flows. Since these flows tend to use very small packets, they have
>very bad efficiency. So perhaps tunnels could be used in order to group
>these flows. The drawback is that they add small delays, i.e. the waiting
>time in the multiplexer. So another use is to provide flexibility: if you
>are a game provider, you may over provision your network in order to be able
>to manage traffic peaks. But perhaps using this, you may be able to have a
>smaller network, and use compression when necessary (rush hour, first days
>after releasing a new game, etc). When traffic is small, you do not
>multiplex, in order to reduce latency.
>
>So if traffic classification is a standard, everyone in the way from the
>origin to the destination will handle the traffic with the correct priority.
>
>I attach a figure in order to clarify.
>
>Thank you,
>
>Jose
>
>PS: In
>http://community.virginmedia.com/t5/Fibre-opt...
>craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
>the history of the problems of World of Warcraft for Virgin Media users. The
>problem was caused by a modification in the traffic, and the provider did
>not notice about it, so it treated the packets as best-effort.
>
>-----Mensaje original-----
>De:   Enviado el:
>jueves, 05 de abril de 2012 9:49
>Para: 
>CC: 
>Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>Jose,
>
>you raise an interesting point:
>
>draft-polk-tsvwg-rfc4594-update suggests to standardise application to
>codepoint mapping as well as codepoint to class properties. You observe that
>some games are using TCP while others use UDP, which I think is a useful
>level of QoS requirement abstraction. There's no need to have like 25+ QoS
>(sub)classes, I think. But one class optimised to transport  "UDP" and one
>for "TCP" are agreeable.
>
>The feedback that I had on carrier class QoS usage is that there's a point
>in standardising class properties, and certainly not to standardise
>application mappings to classes (recommending them may however be useful).
>My take would be to standardise four classes/properties (in brackets example
>usage):
>
>a) for traffic which doesn't support re-transmits, requiring lowest delay
>and jitter, having limited volume and packet
>    size, but being loss tolerant (example usage VoIP)
>b) for any other traffic which doesn't support re-transmits (let's say
>traffic with real time like properties, but any
>    packet size and possibly high volume, UDP transport, like IPTV)
>c) for any other traffic which supports re-transmits (QoS traffic using TCP,
>like application signalling and network management traffic)
>d) a default class, for any traffic supporting re-transmits (Best Effort) -
>this class may not be regarded as QoS (or as lowest CoS)
>
>What I can tell ist that many carriers and standards on QoS support 3-4
>classes, having properties as described above. It is useful to recommend
>codepoints matching to these classes. Standardising these codepoints
>requires agreement between those having deplyed them. Straightforward for a)
>EF and d) 000000, probably easy for c) being used to transport Network
>Management (CS 6). I'm not aware of common ground for anything else. My
>favourites are:
>
>b) AF4 (GSMA supports this one, RFC4594 also)
>c) AF3 (MEF and GSMA support this one)
>
>Gaming from my point of view would then match to an AF3 or AF4 class, this
>may depend on the implemented application transport. Further details may be
>discussed.
>
>Everything else could be reserved, but shouldn't be recommended. Carriers
>have deployed differing schemes on codepoints and classes. They need coding
>reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
>well as in DSCP space if they should converge to a standardised
>codepoint/class scheme.
>
>I object to any approach standardising a match of classes and applications
>with codepoints as a requirement and I also object to standards leaving no
>spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
>precedence).
>
>Bob Briscoe mentioned the difference between classes and queues and above
>properties can be mapped to queues. If end to end QoS is desired, the same
>class properties must be negotiated end to end. The lower the number of
>classes and codepoints being deployed, the higher the probability of getting
>end to end QoS. I don't support an approach requiring 8 three bit classes
>and 25 or more 6 bit classes and codepoints.
>
>Regards,
>
>Ruediger
>
>________________________________
>
>From:   On Behalf Of
>Jose Saldana
>Sent: Monday, April 02, 2012 12:17 PM
>To: James Polk
>Cc: 
>Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>
>
>James,
>
>
>
>After returning home from IETF 83, I have been reading your draft. I find it
>interesting to standardize the service classes. Otherwise, if each one
>classifies each traffic according to different criteria, Diffserv becomes
>less useful.
>
>
>
>Regarding "Real-time interactive" service class, which refers to online
>gaming (my main research field), I find it really interesting: online games
>are at least as real-time as VoIP is. In most cases, the gamers are a very
>difficult people to deal with. If the latency is high, they leave and never
>return (this statement is not mine, it can be corroborated in the references
>I put below). This has been studied by many research groups, with empirical
>tests using real gamers and adding delay, jitter, packet loss.
>
>
>
>Other question: in the draft it is said that online games use RTP/UDP
>streams. This can be a little confusing. In fact, the vast majority of
>online games do not use RTP, but bare UDP or even TCP. In
>http://www.cn.uni-duesseldorf.de/publications... the
>authors proposed the use of an adaptation of RTP in order to manage gaming
>traffic. But as far as I know, this approach is not used by commercial
>games.
>
>
>
>
>
>A typical classification of today's games is:
>
>
>
>-          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
>Duty: They use UDP
>
>-          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
>World of Warcraft: They normally use TCP, even though some of them use UDP
>
>-          RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or
>UDP
>
>-          Sports games: Since there is a big variety, they have not been
>deeply studied in the literature
>
>
>
>Some research papers supporting this classification, and also the real-time
>requirements of the games:
>
>
>
>First Person Shooters
>
>
>
>-          A survey of traffic models for 17 First Person Shooters can be
>found here. All of them use UDP
>http://www.discover.uottawa.ca/publications/f...
>
>
>
>-          In this paper from my research group, 8 FPS games were analyzed
>in order to compress and multiplex their traffic. Figure 5 shows their
>histograms (inter-packet time and packet size). It can be seen that they
>generate real-time flows, with characteristics very similar to VoIP (packets
>of 60-80 bytes every 15-40 ms):
>http://diec.unizar.es/~jsaldana/personal/comm...
>
>
>
>-          Another paper about FPS using UDP. Section V presents some
>interesting conclusions about routing infrastructure.
>http://www.thefengs.com/wuchang/work/cstrike/...
>
>
>
>-          In this paper the network factors annoying the gamers are
>analyzed. There are also some calculations of the MOS. Above 150 ms the
>quality is bad (something similar to what happens with VoIP)
>http://www.research.ibm.com/netgames2005/pape...
>
>
>
>-          In this one, a MOS model for a FPS (Quake IV) is deployed. It is
>only based on delay and jitter, since packet loss has vevy little influence
>(for this concrete game). Delay above 140 ms produces MOS below 3
>http://www.nas.ewi.tudelft.nl/publications/20...
>
>
>
>-          In this paper, it is found that some FPS work properly even with
>30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150
>OWD) makes MOS go above 3
>http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
>
>
>
>MMORPGs:
>
>-          A traffic model for World of Warcraft:
>http://publik.tuwien.ac.at/files/pub-et_12119...
>
>
>
>-          This one presents a MOS for World of Warcraft. When added delay
>is above 160ms, the MOS is roughly 3.:
>http://publik.tuwien.ac.at/files/PubDat_17020...
>
>
>
>Best regards,
>
>
>
>Jose Saldana

> - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> ECN, and six of them are the DSCP field. So the problem is how to use these
> 6 bits (64 possible values)
> - Network control is 11xxxx, so this uses 16 values
>       -11xx11 are defined in RFC 2474, and remain as only experimentally
> assignable/useable (this uses 4 of these 16 values)
> - This leaves 48 values
> - Best effort is 000000
> - The draft of James proposes 14 values for the DSCP field, which correspond
> to service classes, mapped to application categories.
>
> But Ruediger says that, in his opinion, more than 4 classes are not useful,
> according to current implementations.That's actually not appropriate for an RFC 4594 update - the proper place to
address that requirement is an update to RFC 5127, which will need to be updated
to be consistent with whatever is done to RFC 4594.

Thanks,
--David> -----Original Message-----
> From:   On Behalf Of Jose
> Saldana
> Sent: Saturday, April 07, 2012 8:03 AM
> To: ; James M. Polk
> Cc: 
> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> I have been reading the two messages of Ruediger about Jame's draft. I will
> try to make a "status of the question" and then a proposal. If something is
> wrong, just tell me.
>
> - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> ECN, and six of them are the DSCP field. So the problem is how to use these
> 6 bits (64 possible values)
> - Network control is 11xxxx, so this uses 16 values
>       -11xx11 are defined in RFC 2474, and remain as only experimentally
> assignable/useable (this uses 4 of these 16 values)
> - This leaves 48 values
> - Best effort is 000000
> - The draft of James proposes 14 values for the DSCP field, which correspond
> to service classes, mapped to application categories.
>
> But Ruediger says that, in his opinion, more than 4 classes are not useful,
> according to current implementations.
>
> We can ask ourselves: which are  the key parameters that define how packets
> have to be managed in a router? I think that they are:
>
> 1) "Real-time-ness": The tolerated delay of the service. The jitter can be
> roughly included in this parameter.
> 2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
> since they retransmit packets. And some UDP services are also tolerant to
> loss (VoIP, some games, etc)
>
> In my opinion, the "real-time-ness" is the key: it distinguishes very
> similar services: e.g. a video conference is different from a broadcast,
> since the latter permits delays of some seconds, whereas the first has to be
> interactive.
>
> So one possible solution could be:
>
> - Using the first two bits in order to define 4 classes, taking into account
> the existing implementations. They can be the 4 classes of Fig. 1 of James'
> draft, or the ones proposed by Ruediger.
>       00xxxx  best effort
>       01xxxx data
>       10xxxx media oriented
>       11xxxx control
>
> - With the other 4 bits, something should be done. My proposal:
>       - If the third bit is "1", then the other three bits include a value
> defining the "real-time-ness" of the flow. So we have 8 levels of
> real-time-ness. Some examples:
>               - 10-1-111 would be a  media-oriented (10) and very
> real-time flow, as VoIP or a game
>               - 10-0-xxx would be a media-oriented flow for which the
> real-time-ness is not defined
>               - 10-1-010 could be a media-oriented flow with medium delay
> requirements, as multimedia conferencing
>               - 10-1-000 would be a media-oriented flow with no very hard
> delay requirements, as multimedia streaming
>               - 00-xxxx would be best-effort
>               -01-1-111 would be very low-latency data
>               -01-1-000 would be low-priority data
>
> One advantage of this is that some routers may only take into account the
> first two bits, and others would use all of them.
>
> The new RFC could suggest or define different values of real-time-ness for
> each application. So the applications should be ordered depending of the
> maximum tolerated delay.
>
> Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
> Regards,
>
> Jose
>
> -----Mensaje original-----
> De:  
> Enviado el: jueves, 05 de abril de 2012 12:23
> Para: 
> CC: 
> Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Jose,
>
> regarding QoS, I'm happy to agree on 4 standard classes with properties as
> mentioned in my last email. If there's consensus on some codepoints for
> them, I'll support that.
>
> If IETF recommends how and which applications to use these
> classes/codepoints, that's again agreeable. I don't think, that by now
> requiring a specific application to carry a specific DSCP makes sense, apart
> from few exceptions (like VoIP payload, network management traffic or Best
> Effort traffic).
> IETF needs consensus to do that.
> Note that the number of AF classes and codepoints are troublesome. Too many
> with too little explanation how to use them, nothing is aligned with user
> demand. EF/VoIP payload and network management are examples how to proceed:
> just specify what's required, no extras.
>
>
> Then regarding tunnels and header compression Yes, that's smart and there
> may be more use cases than gaming. I'm a backbone engineer however and your
> proposal is rather application specific. What I can do is ask some
> colleagues on their view. But there's no guarantee, that they will respond.
>
> Some initial thoughts:
> To me a key point seems to be what can be reached at the bottleneck. There
> the compression should save bandwidth with little cost and no negative
> service impact. Any kind of shared access from which traffic is transmitted
> to the same destination seems to be relevant. The application/tunnel
> awareness of network elements may not be feasible, a network terminal at a
> UNI may be able to handle that, or any service specific device in a network.
>
> Regards,
>
> Ruediger
>
>
> -----Original Message-----
> From: Jose Saldana 
> Sent: Thursday, April 05, 2012 11:29 AM
> To: Geib, Rüdiger
> Cc: 
> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Ruediger,
>
> I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
> know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
> after talking to James, I thought that the idea of standardizing the traffic
> classification fits well with my proposal. I would like to know your opinion
> about it, if possible.
>
> The idea is to use tunnels in order to compress and multiplex real-time
> traffic flows. Since these flows tend to use very small packets, they have
> very bad efficiency. So perhaps tunnels could be used in order to group
> these flows. The drawback is that they add small delays, i.e. the waiting
> time in the multiplexer. So another use is to provide flexibility: if you
> are a game provider, you may over provision your network in order to be able
> to manage traffic peaks. But perhaps using this, you may be able to have a
> smaller network, and use compression when necessary (rush hour, first days
> after releasing a new game, etc). When traffic is small, you do not
> multiplex, in order to reduce latency.
>
> So if traffic classification is a standard, everyone in the way from the
> origin to the destination will handle the traffic with the correct priority.
>
> I attach a figure in order to clarify.
>
> Thank you,
>
> Jose
>
> PS: In
> http://community.virginmedia.com/t5/Fibre-opt...
> craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
> the history of the problems of World of Warcraft for Virgin Media users. The
> problem was caused by a modification in the traffic, and the provider did
> not notice about it, so it treated the packets as best-effort.
>
> -----Mensaje original-----
> De:   Enviado el:
> jueves, 05 de abril de 2012 9:49
> Para: 
> CC: 
> Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Jose,
>
> you raise an interesting point:
>
> draft-polk-tsvwg-rfc4594-update suggests to standardise application to
> codepoint mapping as well as codepoint to class properties. You observe that
> some games are using TCP while others use UDP, which I think is a useful
> level of QoS requirement abstraction. There's no need to have like 25+ QoS
> (sub)classes, I think. But one class optimised to transport  "UDP" and one
> for "TCP" are agreeable.
>
> The feedback that I had on carrier class QoS usage is that there's a point
> in standardising class properties, and certainly not to standardise
> application mappings to classes (recommending them may however be useful).
> My take would be to standardise four classes/properties (in brackets example
> usage):
>
> a) for traffic which doesn't support re-transmits, requiring lowest delay
> and jitter, having limited volume and packet
>    size, but being loss tolerant (example usage VoIP)
> b) for any other traffic which doesn't support re-transmits (let's say
> traffic with real time like properties, but any
>    packet size and possibly high volume, UDP transport, like IPTV)
> c) for any other traffic which supports re-transmits (QoS traffic using TCP,
> like application signalling and network management traffic)
> d) a default class, for any traffic supporting re-transmits (Best Effort) -
> this class may not be regarded as QoS (or as lowest CoS)
>
> What I can tell ist that many carriers and standards on QoS support 3-4
> classes, having properties as described above. It is useful to recommend
> codepoints matching to these classes. Standardising these codepoints
> requires agreement between those having deplyed them. Straightforward for a)
> EF and d) 000000, probably easy for c) being used to transport Network
> Management (CS 6). I'm not aware of common ground for anything else. My
> favourites are:
>
> b) AF4 (GSMA supports this one, RFC4594 also)
> c) AF3 (MEF and GSMA support this one)
>
> Gaming from my point of view would then match to an AF3 or AF4 class, this
> may depend on the implemented application transport. Further details may be
> discussed.
>
> Everything else could be reserved, but shouldn't be recommended. Carriers
> have deployed differing schemes on codepoints and classes. They need coding
> reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
> well as in DSCP space if they should converge to a standardised
> codepoint/class scheme.
>
> I object to any approach standardising a match of classes and applications
> with codepoints as a requirement and I also object to standards leaving no
> spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
> precedence).
>
> Bob Briscoe mentioned the difference between classes and queues and above
> properties can be mapped to queues. If end to end QoS is desired, the same
> class properties must be negotiated end to end. The lower the number of
> classes and codepoints being deployed, the higher the probability of getting
> end to end QoS. I don't support an approach requiring 8 three bit classes
> and 25 or more 6 bit classes and codepoints.
>
> Regards,
>
> Ruediger
>
> ________________________________
>
> From:   On Behalf Of
> Jose Saldana
> Sent: Monday, April 02, 2012 12:17 PM
> To: James Polk
> Cc: 
> Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>
>
> James,
>
>
>
> After returning home from IETF 83, I have been reading your draft. I find it
> interesting to standardize the service classes. Otherwise, if each one
> classifies each traffic according to different criteria, Diffserv becomes
> less useful.
>
>
>
> Regarding "Real-time interactive" service class, which refers to online
> gaming (my main research field), I find it really interesting: online games
> are at least as real-time as VoIP is. In most cases, the gamers are a very
> difficult people to deal with. If the latency is high, they leave and never
> return (this statement is not mine, it can be corroborated in the references
> I put below). This has been studied by many research groups, with empirical
> tests using real gamers and adding delay, jitter, packet loss.
>
>
>
> Other question: in the draft it is said that online games use RTP/UDP
> streams. This can be a little confusing. In fact, the vast majority of
> online games do not use RTP, but bare UDP or even TCP. In
> http://www.cn.uni-duesseldorf.de/publications... the
> authors proposed the use of an adaptation of RTP in order to manage gaming
> traffic. But as far as I know, this approach is not used by commercial
> games.
>
>
>
>
>
> A typical classification of today's games is:
>
>
>
> -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
> Duty: They use UDP
>
> -          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
> World of Warcraft: They normally use TCP, even though some of them use UDP
>
> -          RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or
> UDP
>
> -          Sports games: Since there is a big variety, they have not been
> deeply studied in the literature
>
>
>
> Some research papers supporting this classification, and also the real-time
> requirements of the games:
>
>
>
> First Person Shooters
>
>
>
> -          A survey of traffic models for 17 First Person Shooters can be
> found here. All of them use UDP
> http://www.discover.uottawa.ca/publications/f...
>
>
>
> -          In this paper from my research group, 8 FPS games were analyzed
> in order to compress and multiplex their traffic. Figure 5 shows their
> histograms (inter-packet time and packet size). It can be seen that they
> generate real-time flows, with characteristics very similar to VoIP (packets
> of 60-80 bytes every 15-40 ms):
> http://diec.unizar.es/~jsaldana/personal/comm...
>
>
>
> -          Another paper about FPS using UDP. Section V presents some
> interesting conclusions about routing infrastructure.
> http://www.thefengs.com/wuchang/work/cstrike/...
>
>
>
> -          In this paper the network factors annoying the gamers are
> analyzed. There are also some calculations of the MOS. Above 150 ms the
> quality is bad (something similar to what happens with VoIP)
> http://www.research.ibm.com/netgames2005/pape...
>
>
>
> -          In this one, a MOS model for a FPS (Quake IV) is deployed. It is
> only based on delay and jitter, since packet loss has vevy little influence
> (for this concrete game). Delay above 140 ms produces MOS below 3
> http://www.nas.ewi.tudelft.nl/publications/20...
>
>
>
> -          In this paper, it is found that some FPS work properly even with
> 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150
> OWD) makes MOS go above 3
> http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
>
>
>
> MMORPGs:
>
> -          A traffic model for World of Warcraft:
> http://publik.tuwien.ac.at/files/pub-et_12119...
>
>
>
> -          This one presents a MOS for World of Warcraft. When added delay
> is above 160ms, the MOS is roughly 3.:
> http://publik.tuwien.ac.at/files/PubDat_17020...
>
>
>
> Best regards,
>
>
>
> Jose Saldana
>
>

David,

taking a formal point of view, you are probably right. These isues are
intertwined however.

End to end QoS will certainly not result from continuing to act like
almost all standards bodies did so far: as there's a lot flexibility
and little non-ambiguous guidance, anything is customised.

I don't regard the update of RFC 4594 as being helpful if the
expectation of the author is that even supporters of that standard
will only deploy a subset of the defined classes and sub classes. Those
standards close to deployment I know offer 3-4 classes and require no
more than 6 codepoints (the latter is personal judgement).

Any standards track QoS document should only determine things seeing
widespread deployment.

Some QoS classes have seen deployment. It's trickier with codepoints.

Anything which might be useful in future or has seen an informational
proposal in past  should be critically reviewed and remain
informational or experimental.

Any QoS class should be well defined any easy to be differentiated
against others.

QoS codepoints should not identify applications.

I also don't think that one needs to differentiate "admitted" from
"non-admitted" classes. In a traffic engineered DiffServ network,
customers get an SLA describing the worst case QoS class performance.
To me it doesn't matter how a carrier ensures that the SLAs are kept.
It only matters that they are kept.

Regards,

Ruediger> - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> ECN, and six of them are the DSCP field. So the problem is how to use these
> 6 bits (64 possible values)
> - Network control is 11xxxx, so this uses 16 values
>       -11xx11 are defined in RFC 2474, and remain as only experimentally
> assignable/useable (this uses 4 of these 16 values)
> - This leaves 48 values
> - Best effort is 000000
> - The draft of James proposes 14 values for the DSCP field, which correspond
> to service classes, mapped to application categories.
>
> But Ruediger says that, in his opinion, more than 4 classes are not useful,
> according to current implementations.That's actually not appropriate for an RFC 4594 update - the proper place to
address that requirement is an update to RFC 5127, which will need to be updated
to be consistent with whatever is done to RFC 4594.

Thanks,
--David> -----Original Message-----
> From:   On Behalf Of Jose
> Saldana
> Sent: Saturday, April 07, 2012 8:03 AM
> To: ; James M. Polk
> Cc: 
> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> I have been reading the two messages of Ruediger about Jame's draft. I will
> try to make a "status of the question" and then a proposal. If something is
> wrong, just tell me.
>
> - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> ECN, and six of them are the DSCP field. So the problem is how to use these
> 6 bits (64 possible values)
> - Network control is 11xxxx, so this uses 16 values
>       -11xx11 are defined in RFC 2474, and remain as only experimentally
> assignable/useable (this uses 4 of these 16 values)
> - This leaves 48 values
> - Best effort is 000000
> - The draft of James proposes 14 values for the DSCP field, which correspond
> to service classes, mapped to application categories.
>
> But Ruediger says that, in his opinion, more than 4 classes are not useful,
> according to current implementations.
>
> We can ask ourselves: which are  the key parameters that define how packets
> have to be managed in a router? I think that they are:
>
> 1) "Real-time-ness": The tolerated delay of the service. The jitter can be
> roughly included in this parameter.
> 2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
> since they retransmit packets. And some UDP services are also tolerant to
> loss (VoIP, some games, etc)
>
> In my opinion, the "real-time-ness" is the key: it distinguishes very
> similar services: e.g. a video conference is different from a broadcast,
> since the latter permits delays of some seconds, whereas the first has to be
> interactive.
>
> So one possible solution could be:
>
> - Using the first two bits in order to define 4 classes, taking into account
> the existing implementations. They can be the 4 classes of Fig. 1 of James'
> draft, or the ones proposed by Ruediger.
>       00xxxx  best effort
>       01xxxx data
>       10xxxx media oriented
>       11xxxx control
>
> - With the other 4 bits, something should be done. My proposal:
>       - If the third bit is "1", then the other three bits include a value
> defining the "real-time-ness" of the flow. So we have 8 levels of
> real-time-ness. Some examples:
>               - 10-1-111 would be a  media-oriented (10) and very
> real-time flow, as VoIP or a game
>               - 10-0-xxx would be a media-oriented flow for which the
> real-time-ness is not defined
>               - 10-1-010 could be a media-oriented flow with medium delay
> requirements, as multimedia conferencing
>               - 10-1-000 would be a media-oriented flow with no very hard
> delay requirements, as multimedia streaming
>               - 00-xxxx would be best-effort
>               -01-1-111 would be very low-latency data
>               -01-1-000 would be low-priority data
>
> One advantage of this is that some routers may only take into account the
> first two bits, and others would use all of them.
>
> The new RFC could suggest or define different values of real-time-ness for
> each application. So the applications should be ordered depending of the
> maximum tolerated delay.
>
> Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
> Regards,
>
> Jose
>
> -----Mensaje original-----
> De:  
> Enviado el: jueves, 05 de abril de 2012 12:23
> Para: 
> CC: 
> Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Jose,
>
> regarding QoS, I'm happy to agree on 4 standard classes with properties as
> mentioned in my last email. If there's consensus on some codepoints for
> them, I'll support that.
>
> If IETF recommends how and which applications to use these
> classes/codepoints, that's again agreeable. I don't think, that by now
> requiring a specific application to carry a specific DSCP makes sense, apart
> from few exceptions (like VoIP payload, network management traffic or Best
> Effort traffic).
> IETF needs consensus to do that.
> Note that the number of AF classes and codepoints are troublesome. Too many
> with too little explanation how to use them, nothing is aligned with user
> demand. EF/VoIP payload and network management are examples how to proceed:
> just specify what's required, no extras.
>
>
> Then regarding tunnels and header compression Yes, that's smart and there
> may be more use cases than gaming. I'm a backbone engineer however and your
> proposal is rather application specific. What I can do is ask some
> colleagues on their view. But there's no guarantee, that they will respond.
>
> Some initial thoughts:
> To me a key point seems to be what can be reached at the bottleneck. There
> the compression should save bandwidth with little cost and no negative
> service impact. Any kind of shared access from which traffic is transmitted
> to the same destination seems to be relevant. The application/tunnel
> awareness of network elements may not be feasible, a network terminal at a
> UNI may be able to handle that, or any service specific device in a network.
>
> Regards,
>
> Ruediger
>
>
> -----Original Message-----
> From: Jose Saldana 
> Sent: Thursday, April 05, 2012 11:29 AM
> To: Geib, Rüdiger
> Cc: 
> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Ruediger,
>
> I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
> know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
> after talking to James, I thought that the idea of standardizing the traffic
> classification fits well with my proposal. I would like to know your opinion
> about it, if possible.
>
> The idea is to use tunnels in order to compress and multiplex real-time
> traffic flows. Since these flows tend to use very small packets, they have
> very bad efficiency. So perhaps tunnels could be used in order to group
> these flows. The drawback is that they add small delays, i.e. the waiting
> time in the multiplexer. So another use is to provide flexibility: if you
> are a game provider, you may over provision your network in order to be able
> to manage traffic peaks. But perhaps using this, you may be able to have a
> smaller network, and use compression when necessary (rush hour, first days
> after releasing a new game, etc). When traffic is small, you do not
> multiplex, in order to reduce latency.
>
> So if traffic classification is a standard, everyone in the way from the
> origin to the destination will handle the traffic with the correct priority.
>
> I attach a figure in order to clarify.
>
> Thank you,
>
> Jose
>
> PS: In
> http://community.virginmedia.com/t5/Fibre-opt...
> craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
> the history of the problems of World of Warcraft for Virgin Media users. The
> problem was caused by a modification in the traffic, and the provider did
> not notice about it, so it treated the packets as best-effort.
>
> -----Mensaje original-----
> De:   Enviado el:
> jueves, 05 de abril de 2012 9:49
> Para: 
> CC: 
> Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> Jose,
>
> you raise an interesting point:
>
> draft-polk-tsvwg-rfc4594-update suggests to standardise application to
> codepoint mapping as well as codepoint to class properties. You observe that
> some games are using TCP while others use UDP, which I think is a useful
> level of QoS requirement abstraction. There's no need to have like 25+ QoS
> (sub)classes, I think. But one class optimised to transport  "UDP" and one
> for "TCP" are agreeable.
>
> The feedback that I had on carrier class QoS usage is that there's a point
> in standardising class properties, and certainly not to standardise
> application mappings to classes (recommending them may however be useful).
> My take would be to standardise four classes/properties (in brackets example
> usage):
>
> a) for traffic which doesn't support re-transmits, requiring lowest delay
> and jitter, having limited volume and packet
>    size, but being loss tolerant (example usage VoIP)
> b) for any other traffic which doesn't support re-transmits (let's say
> traffic with real time like properties, but any
>    packet size and possibly high volume, UDP transport, like IPTV)
> c) for any other traffic which supports re-transmits (QoS traffic using TCP,
> like application signalling and network management traffic)
> d) a default class, for any traffic supporting re-transmits (Best Effort) -
> this class may not be regarded as QoS (or as lowest CoS)
>
> What I can tell ist that many carriers and standards on QoS support 3-4
> classes, having properties as described above. It is useful to recommend
> codepoints matching to these classes. Standardising these codepoints
> requires agreement between those having deplyed them. Straightforward for a)
> EF and d) 000000, probably easy for c) being used to transport Network
> Management (CS 6). I'm not aware of common ground for anything else. My
> favourites are:
>
> b) AF4 (GSMA supports this one, RFC4594 also)
> c) AF3 (MEF and GSMA support this one)
>
> Gaming from my point of view would then match to an AF3 or AF4 class, this
> may depend on the implemented application transport. Further details may be
> discussed.
>
> Everything else could be reserved, but shouldn't be recommended. Carriers
> have deployed differing schemes on codepoints and classes. They need coding
> reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
> well as in DSCP space if they should converge to a standardised
> codepoint/class scheme.
>
> I object to any approach standardising a match of classes and applications
> with codepoints as a requirement and I also object to standards leaving no
> spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
> precedence).
>
> Bob Briscoe mentioned the difference between classes and queues and above
> properties can be mapped to queues. If end to end QoS is desired, the same
> class properties must be negotiated end to end. The lower the number of
> classes and codepoints being deployed, the higher the probability of getting
> end to end QoS. I don't support an approach requiring 8 three bit classes
> and 25 or more 6 bit classes and codepoints.
>
> Regards,
>
> Ruediger
>
> ________________________________
>
> From:   On Behalf Of
> Jose Saldana
> Sent: Monday, April 02, 2012 12:17 PM
> To: James Polk
> Cc: 
> Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
>
>
>
> James,
>
>
>
> After returning home from IETF 83, I have been reading your draft. I find it
> interesting to standardize the service classes. Otherwise, if each one
> classifies each traffic according to different criteria, Diffserv becomes
> less useful.
>
>
>
> Regarding "Real-time interactive" service class, which refers to online
> gaming (my main research field), I find it really interesting: online games
> are at least as real-time as VoIP is. In most cases, the gamers are a very
> difficult people to deal with. If the latency is high, they leave and never
> return (this statement is not mine, it can be corroborated in the references
> I put below). This has been studied by many research groups, with empirical
> tests using real gamers and adding delay, jitter, packet loss.
>
>
>
> Other question: in the draft it is said that online games use RTP/UDP
> streams. This can be a little confusing. In fact, the vast majority of
> online games do not use RTP, but bare UDP or even TCP. In
> http://www.cn.uni-duesseldorf.de/publications... the
> authors proposed the use of an adaptation of RTP in order to manage gaming
> traffic. But as far as I know, this approach is not used by commercial
> games.
>
>
>
>
>
> A typical classification of today's games is:
>
>
>
> -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
> Duty: They use UDP
>
> -          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
> World of Warcraft: They normally use TCP, even though some of them use UDP
>
> -          RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or
> UDP
>
> -          Sports games: Since there is a big variety, they have not been
> deeply studied in the literature
>
>
>
> Some research papers supporting this classification, and also the real-time
> requirements of the games:
>
>
>
> First Person Shooters
>
>
>
> -          A survey of traffic models for 17 First Person Shooters can be
> found here. All of them use UDP
> http://www.discover.uottawa.ca/publications/f...
>
>
>
> -          In this paper from my research group, 8 FPS games were analyzed
> in order to compress and multiplex their traffic. Figure 5 shows their
> histograms (inter-packet time and packet size). It can be seen that they
> generate real-time flows, with characteristics very similar to VoIP (packets
> of 60-80 bytes every 15-40 ms):
> http://diec.unizar.es/~jsaldana/personal/comm...
>
>
>
> -          Another paper about FPS using UDP. Section V presents some
> interesting conclusions about routing infrastructure.
> http://www.thefengs.com/wuchang/work/cstrike/...
>
>
>
> -          In this paper the network factors annoying the gamers are
> analyzed. There are also some calculations of the MOS. Above 150 ms the
> quality is bad (something similar to what happens with VoIP)
> http://www.research.ibm.com/netgames2005/pape...
>
>
>
> -          In this one, a MOS model for a FPS (Quake IV) is deployed. It is
> only based on delay and jitter, since packet loss has vevy little influence
> (for this concrete game). Delay above 140 ms produces MOS below 3
> http://www.nas.ewi.tudelft.nl/publications/20...
>
>
>
> -          In this paper, it is found that some FPS work properly even with
> 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150
> OWD) makes MOS go above 3
> http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
>
>
>
> MMORPGs:
>
> -          A traffic model for World of Warcraft:
> http://publik.tuwien.ac.at/files/pub-et_12119...
>
>
>
> -          This one presents a MOS for World of Warcraft. When added delay
> is above 160ms, the MOS is roughly 3.:
> http://publik.tuwien.ac.at/files/PubDat_17020...
>
>
>
> Best regards,
>
>
>
> Jose Saldana
>
>

Ruediger,

We may be disagreeing more about means than ends.

RFC 5127's intent was to aggregate all of the classes defined in RFC 4594
into a much smaller number of classes that would be suitable for a core
network,  e.g., "3-4 classes and require no more than 6 codepoints".  The
net would be that a choice of considerably more traffic classes from RFC
4594 would be deployable via aggregation as a suitably small number of
classes on the wire.

I believe (and I've said so to James), that RFC 5127 needs to be revised
in concert with any work on RFC 4594 (in particular, I strongly oppose any
revision to 4594 that ignores 5127).  I also think that RFC 5127 is a
better starting point to address the small number of classes use case
that appears to be of interest and concern to you.

Thanks,
--David> -----Original Message-----
> From:  
> Sent: Tuesday, April 24, 2012 5:56 AM
> To: Black, David
> Cc: 
> Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
>
> David,
>
> taking a formal point of view, you are probably right. These isues are
> intertwined however.
>
> End to end QoS will certainly not result from continuing to act like
> almost all standards bodies did so far: as there's a lot flexibility
> and little non-ambiguous guidance, anything is customised.
>
> I don't regard the update of RFC 4594 as being helpful if the
> expectation of the author is that even supporters of that standard
> will only deploy a subset of the defined classes and sub classes. Those
> standards close to deployment I know offer 3-4 classes and require no
> more than 6 codepoints (the latter is personal judgement).
>
> Any standards track QoS document should only determine things seeing
> widespread deployment.
>
> Some QoS classes have seen deployment. It's trickier with codepoints.
>
> Anything which might be useful in future or has seen an informational
> proposal in past  should be critically reviewed and remain
> informational or experimental.
>
> Any QoS class should be well defined any easy to be differentiated
> against others.
>
> QoS codepoints should not identify applications.
>
> I also don't think that one needs to differentiate "admitted" from
> "non-admitted" classes. In a traffic engineered DiffServ network,
> customers get an SLA describing the worst case QoS class performance.
> To me it doesn't matter how a carrier ensures that the SLAs are kept.
> It only matters that they are kept.
>
> Regards,
>
> Ruediger
>
>
> > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> > ECN, and six of them are the DSCP field. So the problem is how to use these
> > 6 bits (64 possible values)
> > - Network control is 11xxxx, so this uses 16 values
> >       -11xx11 are defined in RFC 2474, and remain as only experimentally
> > assignable/useable (this uses 4 of these 16 values)
> > - This leaves 48 values
> > - Best effort is 000000
> > - The draft of James proposes 14 values for the DSCP field, which correspond
> > to service classes, mapped to application categories.
> >
> > But Ruediger says that, in his opinion, more than 4 classes are not useful,
> > according to current implementations.
>
> That's actually not appropriate for an RFC 4594 update - the proper place to
> address that requirement is an update to RFC 5127, which will need to be
> updated
> to be consistent with whatever is done to RFC 4594.
>
> Thanks,
> --David
>
>
> > -----Original Message-----
> > From:   On Behalf Of
> Jose
> > Saldana
> > Sent: Saturday, April 07, 2012 8:03 AM
> > To: ; James M. Polk
> > Cc: 
> > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > I have been reading the two messages of Ruediger about Jame's draft. I will
> > try to make a "status of the question" and then a proposal. If something is
> > wrong, just tell me.
> >
> > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> > ECN, and six of them are the DSCP field. So the problem is how to use these
> > 6 bits (64 possible values)
> > - Network control is 11xxxx, so this uses 16 values
> >       -11xx11 are defined in RFC 2474, and remain as only experimentally
> > assignable/useable (this uses 4 of these 16 values)
> > - This leaves 48 values
> > - Best effort is 000000
> > - The draft of James proposes 14 values for the DSCP field, which correspond
> > to service classes, mapped to application categories.
> >
> > But Ruediger says that, in his opinion, more than 4 classes are not useful,
> > according to current implementations.
> >
> > We can ask ourselves: which are  the key parameters that define how packets
> > have to be managed in a router? I think that they are:
> >
> > 1) "Real-time-ness": The tolerated delay of the service. The jitter can be
> > roughly included in this parameter.
> > 2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
> > since they retransmit packets. And some UDP services are also tolerant to
> > loss (VoIP, some games, etc)
> >
> > In my opinion, the "real-time-ness" is the key: it distinguishes very
> > similar services: e.g. a video conference is different from a broadcast,
> > since the latter permits delays of some seconds, whereas the first has to be
> > interactive.
> >
> > So one possible solution could be:
> >
> > - Using the first two bits in order to define 4 classes, taking into account
> > the existing implementations. They can be the 4 classes of Fig. 1 of James'
> > draft, or the ones proposed by Ruediger.
> >       00xxxx  best effort
> >       01xxxx data
> >       10xxxx media oriented
> >       11xxxx control
> >
> > - With the other 4 bits, something should be done. My proposal:
> >       - If the third bit is "1", then the other three bits include a value
> > defining the "real-time-ness" of the flow. So we have 8 levels of
> > real-time-ness. Some examples:
> >               - 10-1-111 would be a  media-oriented (10) and very
> > real-time flow, as VoIP or a game
> >               - 10-0-xxx would be a media-oriented flow for which the
> > real-time-ness is not defined
> >               - 10-1-010 could be a media-oriented flow with medium delay
> > requirements, as multimedia conferencing
> >               - 10-1-000 would be a media-oriented flow with no very hard
> > delay requirements, as multimedia streaming
> >               - 00-xxxx would be best-effort
> >               -01-1-111 would be very low-latency data
> >               -01-1-000 would be low-priority data
> >
> > One advantage of this is that some routers may only take into account the
> > first two bits, and others would use all of them.
> >
> > The new RFC could suggest or define different values of real-time-ness for
> > each application. So the applications should be ordered depending of the
> > maximum tolerated delay.
> >
> > Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
> > Regards,
> >
> > Jose
> >
> > -----Mensaje original-----
> > De:  
> > Enviado el: jueves, 05 de abril de 2012 12:23
> > Para: 
> > CC: 
> > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > Jose,
> >
> > regarding QoS, I'm happy to agree on 4 standard classes with properties as
> > mentioned in my last email. If there's consensus on some codepoints for
> > them, I'll support that.
> >
> > If IETF recommends how and which applications to use these
> > classes/codepoints, that's again agreeable. I don't think, that by now
> > requiring a specific application to carry a specific DSCP makes sense, apart
> > from few exceptions (like VoIP payload, network management traffic or Best
> > Effort traffic).
> > IETF needs consensus to do that.
> > Note that the number of AF classes and codepoints are troublesome. Too many
> > with too little explanation how to use them, nothing is aligned with user
> > demand. EF/VoIP payload and network management are examples how to proceed:
> > just specify what's required, no extras.
> >
> >
> > Then regarding tunnels and header compression Yes, that's smart and there
> > may be more use cases than gaming. I'm a backbone engineer however and your
> > proposal is rather application specific. What I can do is ask some
> > colleagues on their view. But there's no guarantee, that they will respond.
> >
> > Some initial thoughts:
> > To me a key point seems to be what can be reached at the bottleneck. There
> > the compression should save bandwidth with little cost and no negative
> > service impact. Any kind of shared access from which traffic is transmitted
> > to the same destination seems to be relevant. The application/tunnel
> > awareness of network elements may not be feasible, a network terminal at a
> > UNI may be able to handle that, or any service specific device in a network.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > -----Original Message-----
> > From: Jose Saldana 
> > Sent: Thursday, April 05, 2012 11:29 AM
> > To: Geib, Rüdiger
> > Cc: 
> > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > Ruediger,
> >
> > I have read your message about draft-polk-tsvwg-rfc4594-update. As you may
> > know, I presented another draft in Paris (draft-saldana-tsvwg-tcmtf-02), and
> > after talking to James, I thought that the idea of standardizing the traffic
> > classification fits well with my proposal. I would like to know your opinion
> > about it, if possible.
> >
> > The idea is to use tunnels in order to compress and multiplex real-time
> > traffic flows. Since these flows tend to use very small packets, they have
> > very bad efficiency. So perhaps tunnels could be used in order to group
> > these flows. The drawback is that they add small delays, i.e. the waiting
> > time in the multiplexer. So another use is to provide flexibility: if you
> > are a game provider, you may over provision your network in order to be able
> > to manage traffic peaks. But perhaps using this, you may be able to have a
> > smaller network, and use compression when necessary (rush hour, first days
> > after releasing a new game, etc). When traffic is small, you do not
> > multiplex, in order to reduce latency.
> >
> > So if traffic classification is a standard, everyone in the way from the
> > origin to the destination will handle the traffic with the correct priority.
> >
> > I attach a figure in order to clarify.
> >
> > Thank you,
> >
> > Jose
> >
> > PS: In
> > http://community.virginmedia.com/t5/Fibre-opt...
> > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
> > the history of the problems of World of Warcraft for Virgin Media users. The
> > problem was caused by a modification in the traffic, and the provider did
> > not notice about it, so it treated the packets as best-effort.
> >
> > -----Mensaje original-----
> > De:   Enviado el:
> > jueves, 05 de abril de 2012 9:49
> > Para: 
> > CC: 
> > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > Jose,
> >
> > you raise an interesting point:
> >
> > draft-polk-tsvwg-rfc4594-update suggests to standardise application to
> > codepoint mapping as well as codepoint to class properties. You observe that
> > some games are using TCP while others use UDP, which I think is a useful
> > level of QoS requirement abstraction. There's no need to have like 25+ QoS
> > (sub)classes, I think. But one class optimised to transport  "UDP" and one
> > for "TCP" are agreeable.
> >
> > The feedback that I had on carrier class QoS usage is that there's a point
> > in standardising class properties, and certainly not to standardise
> > application mappings to classes (recommending them may however be useful).
> > My take would be to standardise four classes/properties (in brackets example
> > usage):
> >
> > a) for traffic which doesn't support re-transmits, requiring lowest delay
> > and jitter, having limited volume and packet
> >    size, but being loss tolerant (example usage VoIP)
> > b) for any other traffic which doesn't support re-transmits (let's say
> > traffic with real time like properties, but any
> >    packet size and possibly high volume, UDP transport, like IPTV)
> > c) for any other traffic which supports re-transmits (QoS traffic using TCP,
> > like application signalling and network management traffic)
> > d) a default class, for any traffic supporting re-transmits (Best Effort) -
> > this class may not be regarded as QoS (or as lowest CoS)
> >
> > What I can tell ist that many carriers and standards on QoS support 3-4
> > classes, having properties as described above. It is useful to recommend
> > codepoints matching to these classes. Standardising these codepoints
> > requires agreement between those having deplyed them. Straightforward for a)
> > EF and d) 000000, probably easy for c) being used to transport Network
> > Management (CS 6). I'm not aware of common ground for anything else. My
> > favourites are:
> >
> > b) AF4 (GSMA supports this one, RFC4594 also)
> > c) AF3 (MEF and GSMA support this one)
> >
> > Gaming from my point of view would then match to an AF3 or AF4 class, this
> > may depend on the implemented application transport. Further details may be
> > discussed.
> >
> > Everything else could be reserved, but shouldn't be recommended. Carriers
> > have deployed differing schemes on codepoints and classes. They need coding
> > reserverves in 3 bit space (MPLS TC, IP Precedence and Ethernet P-Bits) as
> > well as in DSCP space if they should converge to a standardised
> > codepoint/class scheme.
> >
> > I object to any approach standardising a match of classes and applications
> > with codepoints as a requirement and I also object to standards leaving no
> > spare codepoints in 3 bit or 6 bit QoS codepoint space (including 3 bit IP
> > precedence).
> >
> > Bob Briscoe mentioned the difference between classes and queues and above
> > properties can be mapped to queues. If end to end QoS is desired, the same
> > class properties must be negotiated end to end. The lower the number of
> > classes and codepoints being deployed, the higher the probability of getting
> > end to end QoS. I don't support an approach requiring 8 three bit classes
> > and 25 or more 6 bit classes and codepoints.
> >
> > Regards,
> >
> > Ruediger
> >
> > ________________________________
> >
> > From:   On Behalf Of
> > Jose Saldana
> > Sent: Monday, April 02, 2012 12:17 PM
> > To: James Polk
> > Cc: 
> > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> >
> >
> > James,
> >
> >
> >
> > After returning home from IETF 83, I have been reading your draft. I find it
> > interesting to standardize the service classes. Otherwise, if each one
> > classifies each traffic according to different criteria, Diffserv becomes
> > less useful.
> >
> >
> >
> > Regarding "Real-time interactive" service class, which refers to online
> > gaming (my main research field), I find it really interesting: online games
> > are at least as real-time as VoIP is. In most cases, the gamers are a very
> > difficult people to deal with. If the latency is high, they leave and never
> > return (this statement is not mine, it can be corroborated in the references
> > I put below). This has been studied by many research groups, with empirical
> > tests using real gamers and adding delay, jitter, packet loss.
> >
> >
> >
> > Other question: in the draft it is said that online games use RTP/UDP
> > streams. This can be a little confusing. In fact, the vast majority of
> > online games do not use RTP, but bare UDP or even TCP. In
> > http://www.cn.uni-duesseldorf.de/publications... the
> > authors proposed the use of an adaptation of RTP in order to manage gaming
> > traffic. But as far as I know, this approach is not used by commercial
> > games.
> >
> >
> >
> >
> >
> > A typical classification of today's games is:
> >
> >
> >
> > -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
> > Duty: They use UDP
> >
> > -          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
> > World of Warcraft: They normally use TCP, even though some of them use UDP
> >
> > -          RTS (Real-time strategy) e.g. Age of Empires: They may use TCP or
> > UDP
> >
> > -          Sports games: Since there is a big variety, they have not been
> > deeply studied in the literature
> >
> >
> >
> > Some research papers supporting this classification, and also the real-time
> > requirements of the games:
> >
> >
> >
> > First Person Shooters
> >
> >
> >
> > -          A survey of traffic models for 17 First Person Shooters can be
> > found here. All of them use UDP
> > http://www.discover.uottawa.ca/publications/f...
> >
> >
> >
> > -          In this paper from my research group, 8 FPS games were analyzed
> > in order to compress and multiplex their traffic. Figure 5 shows their
> > histograms (inter-packet time and packet size). It can be seen that they
> > generate real-time flows, with characteristics very similar to VoIP (packets
> > of 60-80 bytes every 15-40 ms):
> > http://diec.unizar.es/~jsaldana/personal/comm...
> >
> >
> >
> > -          Another paper about FPS using UDP. Section V presents some
> > interesting conclusions about routing infrastructure.
> > http://www.thefengs.com/wuchang/work/cstrike/...
> >
> >
> >
> > -          In this paper the network factors annoying the gamers are
> > analyzed. There are also some calculations of the MOS. Above 150 ms the
> > quality is bad (something similar to what happens with VoIP)
> > http://www.research.ibm.com/netgames2005/pape...
> >
> >
> >
> > -          In this one, a MOS model for a FPS (Quake IV) is deployed. It is
> > only based on delay and jitter, since packet loss has vevy little influence
> > (for this concrete game). Delay above 140 ms produces MOS below 3
> > http://www.nas.ewi.tudelft.nl/publications/20...
> >
> >
> >
> > -          In this paper, it is found that some FPS work properly even with
> > 30% packet loss, whereas others stop working with 4%. RTT above 300 ms (150
> > OWD) makes MOS go above 3
> > http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
> >
> >
> >
> > MMORPGs:
> >
> > -          A traffic model for World of Warcraft:
> > http://publik.tuwien.ac.at/files/pub-et_12119...
> >
> >
> >
> > -          This one presents a MOS for World of Warcraft. When added delay
> > is above 160ms, the MOS is roughly 3.:
> > http://publik.tuwien.ac.at/files/PubDat_17020...
> >
> >
> >
> > Best regards,
> >
> >
> >
> > Jose Saldana
> >
> >
>

David

I absolutely agree with you that these two 
efforts (the current rewrite of RFC4594, and the 
coming rewrite of RFC5127) need to be 
synchronized to have either make proper sense. I 
also agree that the rewrite of RFC5127 is where a 
smaller, aggregated set of classes for core 
networks. Ruediger mentioned his worry about 
"folks viewing tables and just configuring based 
on the tables". Clearly his concerns on that need to be addressed.

I'll work to get my initial version of the 
rewrite of RFC5127 in before Vancouver.

JamesAt 07:17 PM 4/25/2012,  wrote:
>Ruediger,
>
>We may be disagreeing more about means than ends.
>
>RFC 5127's intent was to aggregate all of the classes defined in RFC 4594
>into a much smaller number of classes that would be suitable for a core
>network,  e.g., "3-4 classes and require no more than 6 codepoints".  The
>net would be that a choice of considerably more traffic classes from RFC
>4594 would be deployable via aggregation as a suitably small number of
>classes on the wire.
>
>I believe (and I've said so to James), that RFC 5127 needs to be revised
>in concert with any work on RFC 4594 (in particular, I strongly oppose any
>revision to 4594 that ignores 5127).  I also think that RFC 5127 is a
>better starting point to address the small number of classes use case
>that appears to be of interest and concern to you.
>
>Thanks,
>--David
>
> > -----Original Message-----
> > From:  
> > Sent: Tuesday, April 24, 2012 5:56 AM
> > To: Black, David
> > Cc: 
> > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > David,
> >
> > taking a formal point of view, you are probably right. These isues are
> > intertwined however.
> >
> > End to end QoS will certainly not result from continuing to act like
> > almost all standards bodies did so far: as there's a lot flexibility
> > and little non-ambiguous guidance, anything is customised.
> >
> > I don't regard the update of RFC 4594 as being helpful if the
> > expectation of the author is that even supporters of that standard
> > will only deploy a subset of the defined classes and sub classes. Those
> > standards close to deployment I know offer 3-4 classes and require no
> > more than 6 codepoints (the latter is personal judgement).
> >
> > Any standards track QoS document should only determine things seeing
> > widespread deployment.
> >
> > Some QoS classes have seen deployment. It's trickier with codepoints.
> >
> > Anything which might be useful in future or has seen an informational
> > proposal in past  should be critically reviewed and remain
> > informational or experimental.
> >
> > Any QoS class should be well defined any easy to be differentiated
> > against others.
> >
> > QoS codepoints should not identify applications.
> >
> > I also don't think that one needs to differentiate "admitted" from
> > "non-admitted" classes. In a traffic engineered DiffServ network,
> > customers get an SLA describing the worst case QoS class performance.
> > To me it doesn't matter how a carrier ensures that the SLAs are kept.
> > It only matters that they are kept.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> > > ECN, and six of them are the DSCP field. So 
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only experimentally
> > > assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for 
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion, 
> more than 4 classes are not useful,
> > > according to current implementations.
> >
> > That's actually not appropriate for an RFC 
> 4594 update - the proper place to
> > address that requirement is an update to RFC 5127, which will need to be
> > updated
> > to be consistent with whatever is done to RFC 4594.
> >
> > Thanks,
> > --David
> >
> >
> > > -----Original Message-----
> > > From:   On Behalf Of
> > Jose
> > > Saldana
> > > Sent: Saturday, April 07, 2012 8:03 AM
> > > To: ; James M. Polk
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > I have been reading the two messages of 
> Ruediger about Jame's draft. I will
> > > try to make a "status of the question" and 
> then a proposal. If something is
> > > wrong, just tell me.
> > >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of them are
> > > ECN, and six of them are the DSCP field. So 
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only experimentally
> > > assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for 
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion, 
> more than 4 classes are not useful,
> > > according to current implementations.
> > >
> > > We can ask ourselves: which are  the key 
> parameters that define how packets
> > > have to be managed in a router? I think that they are:
> > >
> > > 1) "Real-time-ness": The tolerated delay of 
> the service. The jitter can be
> > > roughly included in this parameter.
> > > 2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
> > > since they retransmit packets. And some UDP services are also tolerant to
> > > loss (VoIP, some games, etc)
> > >
> > > In my opinion, the "real-time-ness" is the key: it distinguishes very
> > > similar services: e.g. a video conference is different from a broadcast,
> > > since the latter permits delays of some 
> seconds, whereas the first has to be
> > > interactive.
> > >
> > > So one possible solution could be:
> > >
> > > - Using the first two bits in order to 
> define 4 classes, taking into account
> > > the existing implementations. They can be 
> the 4 classes of Fig. 1 of James'
> > > draft, or the ones proposed by Ruediger.
> > >       00xxxx  best effort
> > >       01xxxx data
> > >       10xxxx media oriented
> > >       11xxxx control
> > >
> > > - With the other 4 bits, something should be done. My proposal:
> > >       - If the third bit is "1", then the 
> other three bits include a value
> > > defining the "real-time-ness" of the flow. So we have 8 levels of
> > > real-time-ness. Some examples:
> > >               - 10-1-111 would be a  media-oriented (10) and very
> > > real-time flow, as VoIP or a game
> > >               - 10-0-xxx would be a media-oriented flow for which the
> > > real-time-ness is not defined
> > >               - 10-1-010 could be a media-oriented flow with medium delay
> > > requirements, as multimedia conferencing
> > >               - 10-1-000 would be a media-oriented flow with no very hard
> > > delay requirements, as multimedia streaming
> > >               - 00-xxxx would be best-effort
> > >               -01-1-111 would be very low-latency data
> > >               -01-1-000 would be low-priority data
> > >
> > > One advantage of this is that some routers may only take into account the
> > > first two bits, and others would use all of them.
> > >
> > > The new RFC could suggest or define 
> different values of real-time-ness for
> > > each application. So the applications should be ordered depending of the
> > > maximum tolerated delay.
> > >
> > > Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
> > > Regards,
> > >
> > > Jose
> > >
> > > -----Mensaje original-----
> > > De:  
> > > Enviado el: jueves, 05 de abril de 2012 12:23
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > regarding QoS, I'm happy to agree on 4 
> standard classes with properties as
> > > mentioned in my last email. If there's consensus on some codepoints for
> > > them, I'll support that.
> > >
> > > If IETF recommends how and which applications to use these
> > > classes/codepoints, that's again agreeable. I don't think, that by now
> > > requiring a specific application to carry a 
> specific DSCP makes sense, apart
> > > from few exceptions (like VoIP payload, 
> network management traffic or Best
> > > Effort traffic).
> > > IETF needs consensus to do that.
> > > Note that the number of AF classes and 
> codepoints are troublesome. Too many
> > > with too little explanation how to use them, nothing is aligned with user
> > > demand. EF/VoIP payload and network 
> management are examples how to proceed:
> > > just specify what's required, no extras.
> > >
> > >
> > > Then regarding tunnels and header compression Yes, that's smart and there
> > > may be more use cases than gaming. I'm a 
> backbone engineer however and your
> > > proposal is rather application specific. What I can do is ask some
> > > colleagues on their view. But there's no 
> guarantee, that they will respond.
> > >
> > > Some initial thoughts:
> > > To me a key point seems to be what can be 
> reached at the bottleneck. There
> > > the compression should save bandwidth with little cost and no negative
> > > service impact. Any kind of shared access 
> from which traffic is transmitted
> > > to the same destination seems to be relevant. The application/tunnel
> > > awareness of network elements may not be 
> feasible, a network terminal at a
> > > UNI may be able to handle that, or any 
> service specific device in a network.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > >
> > > -----Original Message-----
> > > From: Jose Saldana 
> > > Sent: Thursday, April 05, 2012 11:29 AM
> > > To: Geib, Rüdiger
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Ruediger,
> > >
> > > I have read your message about 
> draft-polk-tsvwg-rfc4594-update. As you may
> > > know, I presented another draft in Paris 
> (draft-saldana-tsvwg-tcmtf-02), and
> > > after talking to James, I thought that the 
> idea of standardizing the traffic
> > > classification fits well with my proposal. 
> I would like to know your opinion
> > > about it, if possible.
> > >
> > > The idea is to use tunnels in order to compress and multiplex real-time
> > > traffic flows. Since these flows tend to 
> use very small packets, they have
> > > very bad efficiency. So perhaps tunnels could be used in order to group
> > > these flows. The drawback is that they add small delays, i.e. the waiting
> > > time in the multiplexer. So another use is to provide flexibility: if you
> > > are a game provider, you may over provision 
> your network in order to be able
> > > to manage traffic peaks. But perhaps using 
> this, you may be able to have a
> > > smaller network, and use compression when 
> necessary (rush hour, first days
> > > after releasing a new game, etc). When traffic is small, you do not
> > > multiplex, in order to reduce latency.
> > >
> > > So if traffic classification is a standard, everyone in the way from the
> > > origin to the destination will handle the 
> traffic with the correct priority.
> > >
> > > I attach a figure in order to clarify.
> > >
> > > Thank you,
> > >
> > > Jose
> > >
> > > PS: In
> > > 
> http://community.virginmedia.com/t5/Fibre-opt...
> > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you can find
> > > the history of the problems of World of 
> Warcraft for Virgin Media users. The
> > > problem was caused by a modification in the traffic, and the provider did
> > > not notice about it, so it treated the packets as best-effort.
> > >
> > > -----Mensaje original-----
> > > De:  
>  Enviado el:
> > > jueves, 05 de abril de 2012 9:49
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > you raise an interesting point:
> > >
> > > draft-polk-tsvwg-rfc4594-update suggests to standardise application to
> > > codepoint mapping as well as codepoint to 
> class properties. You observe that
> > > some games are using TCP while others use UDP, which I think is a useful
> > > level of QoS requirement abstraction. 
> There's no need to have like 25+ QoS
> > > (sub)classes, I think. But one class 
> optimised to transport  "UDP" and one
> > > for "TCP" are agreeable.
> > >
> > > The feedback that I had on carrier class 
> QoS usage is that there's a point
> > > in standardising class properties, and certainly not to standardise
> > > application mappings to classes 
> (recommending them may however be useful).
> > > My take would be to standardise four 
> classes/properties (in brackets example
> > > usage):
> > >
> > > a) for traffic which doesn't support re-transmits, requiring lowest delay
> > > and jitter, having limited volume and packet
> > >    size, but being loss tolerant (example usage VoIP)
> > > b) for any other traffic which doesn't support re-transmits (let's say
> > > traffic with real time like properties, but any
> > >    packet size and possibly high volume, UDP transport, like IPTV)
> > > c) for any other traffic which supports 
> re-transmits (QoS traffic using TCP,
> > > like application signalling and network management traffic)
> > > d) a default class, for any traffic 
> supporting re-transmits (Best Effort) -
> > > this class may not be regarded as QoS (or as lowest CoS)
> > >
> > > What I can tell ist that many carriers and standards on QoS support 3-4
> > > classes, having properties as described above. It is useful to recommend
> > > codepoints matching to these classes. Standardising these codepoints
> > > requires agreement between those having 
> deplyed them. Straightforward for a)
> > > EF and d) 000000, probably easy for c) being used to transport Network
> > > Management (CS 6). I'm not aware of common ground for anything else. My
> > > favourites are:
> > >
> > > b) AF4 (GSMA supports this one, RFC4594 also)
> > > c) AF3 (MEF and GSMA support this one)
> > >
> > > Gaming from my point of view would then 
> match to an AF3 or AF4 class, this
> > > may depend on the implemented application 
> transport. Further details may be
> > > discussed.
> > >
> > > Everything else could be reserved, but shouldn't be recommended. Carriers
> > > have deployed differing schemes on 
> codepoints and classes. They need coding
> > > reserverves in 3 bit space (MPLS TC, IP 
> Precedence and Ethernet P-Bits) as
> > > well as in DSCP space if they should converge to a standardised
> > > codepoint/class scheme.
> > >
> > > I object to any approach standardising a 
> match of classes and applications
> > > with codepoints as a requirement and I also 
> object to standards leaving no
> > > spare codepoints in 3 bit or 6 bit QoS 
> codepoint space (including 3 bit IP
> > > precedence).
> > >
> > > Bob Briscoe mentioned the difference between classes and queues and above
> > > properties can be mapped to queues. If end 
> to end QoS is desired, the same
> > > class properties must be negotiated end to end. The lower the number of
> > > classes and codepoints being deployed, the 
> higher the probability of getting
> > > end to end QoS. I don't support an approach requiring 8 three bit classes
> > > and 25 or more 6 bit classes and codepoints.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > ________________________________
> > >
> > > From:   On Behalf Of
> > > Jose Saldana
> > > Sent: Monday, April 02, 2012 12:17 PM
> > > To: James Polk
> > > Cc: 
> > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > >
> > >
> > > James,
> > >
> > >
> > >
> > > After returning home from IETF 83, I have 
> been reading your draft. I find it
> > > interesting to standardize the service classes. Otherwise, if each one
> > > classifies each traffic according to different criteria, Diffserv becomes
> > > less useful.
> > >
> > >
> > >
> > > Regarding "Real-time interactive" service class, which refers to online
> > > gaming (my main research field), I find it 
> really interesting: online games
> > > are at least as real-time as VoIP is. In 
> most cases, the gamers are a very
> > > difficult people to deal with. If the 
> latency is high, they leave and never
> > > return (this statement is not mine, it can 
> be corroborated in the references
> > > I put below). This has been studied by many 
> research groups, with empirical
> > > tests using real gamers and adding delay, jitter, packet loss.
> > >
> > >
> > >
> > > Other question: in the draft it is said that online games use RTP/UDP
> > > streams. This can be a little confusing. In fact, the vast majority of
> > > online games do not use RTP, but bare UDP or even TCP. In
> > > http://www.cn.uni-duesseldorf.de/publications... the
> > > authors proposed the use of an adaptation 
> of RTP in order to manage gaming
> > > traffic. But as far as I know, this approach is not used by commercial
> > > games.
> > >
> > >
> > >
> > >
> > >
> > > A typical classification of today's games is:
> > >
> > >
> > >
> > > -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Call of
> > > Duty: They use UDP
> > >
> > > -          MMORPG (Massively Multiplayer Online Role-playing Games), e.g.
> > > World of Warcraft: They normally use TCP, 
> even though some of them use UDP
> > >
> > > -          RTS (Real-time strategy) e.g. 
> Age of Empires: They may use TCP or
> > > UDP
> > >
> > > -          Sports games: Since there is a big variety, they have not been
> > > deeply studied in the literature
> > >
> > >
> > >
> > > Some research papers supporting this 
> classification, and also the real-time
> > > requirements of the games:
> > >
> > >
> > >
> > > First Person Shooters
> > >
> > >
> > >
> > > -          A survey of traffic models for 17 First Person Shooters can be
> > > found here. All of them use UDP
> > > http://www.discover.uottawa.ca/publications/f...
> > >
> > >
> > >
> > > -          In this paper from my research 
> group, 8 FPS games were analyzed
> > > in order to compress and multiplex their traffic. Figure 5 shows their
> > > histograms (inter-packet time and packet size). It can be seen that they
> > > generate real-time flows, with 
> characteristics very similar to VoIP (packets
> > > of 60-80 bytes every 15-40 ms):
> > > http://diec.unizar.es/~jsaldana/personal/comm...
> > >
> > >
> > >
> > > -          Another paper about FPS using UDP. Section V presents some
> > > interesting conclusions about routing infrastructure.
> > > http://www.thefengs.com/wuchang/work/cstrike/...
> > >
> > >
> > >
> > > -          In this paper the network factors annoying the gamers are
> > > analyzed. There are also some calculations of the MOS. Above 150 ms the
> > > quality is bad (something similar to what happens with VoIP)
> > > http://www.research.ibm.com/netgames2005/pape...
> > >
> > >
> > >
> > > -          In this one, a MOS model for a 
> FPS (Quake IV) is deployed. It is
> > > only based on delay and jitter, since 
> packet loss has vevy little influence
> > > (for this concrete game). Delay above 140 ms produces MOS below 3
> > > http://www.nas.ewi.tudelft.nl/publications/20...
> > >
> > >
> > >
> > > -          In this paper, it is found that 
> some FPS work properly even with
> > > 30% packet loss, whereas others stop 
> working with 4%. RTT above 300 ms (150
> > > OWD) makes MOS go above 3
> > > http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
> > >
> > >
> > >
> > > MMORPGs:
> > >
> > > -          A traffic model for World of Warcraft:
> > > http://publik.tuwien.ac.at/files/pub-et_12119...
> > >
> > >
> > >
> > > -          This one presents a MOS for 
> World of Warcraft. When added delay
> > > is above 160ms, the MOS is roughly 3.:
> > > http://publik.tuwien.ac.at/files/PubDat_17020...
> > >
> > >
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Jose Saldana
> > >
> > >
> >

James,

I think it is clear that people agree with the need of rewriting RFC5127 in
conjunction with RFC4594. I also agree.

If you want, I could help you with that task. Just tell me. Next two months
I think I will have a little more available time.

Jose

-----Mensaje original-----
De:   En nombre de
James M. Polk
Enviado el: jueves, 26 de abril de 2012 23:17
Para: 
CC: 
Asunto: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt

David

I absolutely agree with you that these two efforts (the current rewrite of
RFC4594, and the coming rewrite of RFC5127) need to be synchronized to have
either make proper sense. I also agree that the rewrite of RFC5127 is where
a smaller, aggregated set of classes for core networks. Ruediger mentioned
his worry about "folks viewing tables and just configuring based on the
tables". Clearly his concerns on that need to be addressed.

I'll work to get my initial version of the rewrite of RFC5127 in before
Vancouver.

JamesAt 07:17 PM 4/25/2012,  wrote:
>Ruediger,
>
>We may be disagreeing more about means than ends.
>
>RFC 5127's intent was to aggregate all of the classes defined in RFC 
>4594 into a much smaller number of classes that would be suitable for a 
>core network,  e.g., "3-4 classes and require no more than 6 
>codepoints".  The net would be that a choice of considerably more 
>traffic classes from RFC
>4594 would be deployable via aggregation as a suitably small number of 
>classes on the wire.
>
>I believe (and I've said so to James), that RFC 5127 needs to be 
>revised in concert with any work on RFC 4594 (in particular, I strongly 
>oppose any revision to 4594 that ignores 5127).  I also think that RFC 
>5127 is a better starting point to address the small number of classes 
>use case that appears to be of interest and concern to you.
>
>Thanks,
>--David
>
> > -----Original Message-----
> > From:  
> > Sent: Tuesday, April 24, 2012 5:56 AM
> > To: Black, David
> > Cc: 
> > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > David,
> >
> > taking a formal point of view, you are probably right. These isues 
> > are intertwined however.
> >
> > End to end QoS will certainly not result from continuing to act like 
> > almost all standards bodies did so far: as there's a lot flexibility 
> > and little non-ambiguous guidance, anything is customised.
> >
> > I don't regard the update of RFC 4594 as being helpful if the 
> > expectation of the author is that even supporters of that standard 
> > will only deploy a subset of the defined classes and sub classes. 
> > Those standards close to deployment I know offer 3-4 classes and 
> > require no more than 6 codepoints (the latter is personal judgement).
> >
> > Any standards track QoS document should only determine things seeing 
> > widespread deployment.
> >
> > Some QoS classes have seen deployment. It's trickier with codepoints.
> >
> > Anything which might be useful in future or has seen an 
> > informational proposal in past  should be critically reviewed and 
> > remain informational or experimental.
> >
> > Any QoS class should be well defined any easy to be differentiated 
> > against others.
> >
> > QoS codepoints should not identify applications.
> >
> > I also don't think that one needs to differentiate "admitted" from 
> > "non-admitted" classes. In a traffic engineered DiffServ network, 
> > customers get an SLA describing the worst case QoS class performance.
> > To me it doesn't matter how a carrier ensures that the SLAs are kept.
> > It only matters that they are kept.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of 
> > > them are ECN, and six of them are the DSCP field. So
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only 
> > > experimentally assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion,
> more than 4 classes are not useful,
> > > according to current implementations.
> >
> > That's actually not appropriate for an RFC
> 4594 update - the proper place to
> > address that requirement is an update to RFC 5127, which will need 
> > to be updated to be consistent with whatever is done to RFC 4594.
> >
> > Thanks,
> > --David
> >
> >
> > > -----Original Message-----
> > > From:   On 
> > > Behalf Of
> > Jose
> > > Saldana
> > > Sent: Saturday, April 07, 2012 8:03 AM
> > > To: ; James M. Polk
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > I have been reading the two messages of
> Ruediger about Jame's draft. I will
> > > try to make a "status of the question" and
> then a proposal. If something is
> > > wrong, just tell me.
> > >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of 
> > > them are ECN, and six of them are the DSCP field. So
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only 
> > > experimentally assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion,
> more than 4 classes are not useful,
> > > according to current implementations.
> > >
> > > We can ask ourselves: which are  the key
> parameters that define how packets
> > > have to be managed in a router? I think that they are:
> > >
> > > 1) "Real-time-ness": The tolerated delay of
> the service. The jitter can be
> > > roughly included in this parameter.
> > > 2) loss tolerance: We can distinguish: TCP services are tolerant 
> > > to loss, since they retransmit packets. And some UDP services are 
> > > also tolerant to loss (VoIP, some games, etc)
> > >
> > > In my opinion, the "real-time-ness" is the key: it distinguishes 
> > > very similar services: e.g. a video conference is different from a 
> > > broadcast, since the latter permits delays of some
> seconds, whereas the first has to be
> > > interactive.
> > >
> > > So one possible solution could be:
> > >
> > > - Using the first two bits in order to
> define 4 classes, taking into account
> > > the existing implementations. They can be
> the 4 classes of Fig. 1 of James'
> > > draft, or the ones proposed by Ruediger.
> > >       00xxxx  best effort
> > >       01xxxx data
> > >       10xxxx media oriented
> > >       11xxxx control
> > >
> > > - With the other 4 bits, something should be done. My proposal:
> > >       - If the third bit is "1", then the
> other three bits include a value
> > > defining the "real-time-ness" of the flow. So we have 8 levels of 
> > > real-time-ness. Some examples:
> > >               - 10-1-111 would be a  media-oriented (10) and very 
> > > real-time flow, as VoIP or a game
> > >               - 10-0-xxx would be a media-oriented flow for which 
> > > the real-time-ness is not defined
> > >               - 10-1-010 could be a media-oriented flow with 
> > > medium delay requirements, as multimedia conferencing
> > >               - 10-1-000 would be a media-oriented flow with no 
> > > very hard delay requirements, as multimedia streaming
> > >               - 00-xxxx would be best-effort
> > >               -01-1-111 would be very low-latency data
> > >               -01-1-000 would be low-priority data
> > >
> > > One advantage of this is that some routers may only take into 
> > > account the first two bits, and others would use all of them.
> > >
> > > The new RFC could suggest or define
> different values of real-time-ness for
> > > each application. So the applications should be ordered depending 
> > > of the maximum tolerated delay.
> > >
> > > Ok. This is only an idea. Perhaps it does not make sense. Just tellme.> > > Regards,
> > >
> > > Jose
> > >
> > > -----Mensaje original-----
> > > De:   
> > > Enviado el: jueves, 05 de abril de 2012 12:23
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > regarding QoS, I'm happy to agree on 4
> standard classes with properties as
> > > mentioned in my last email. If there's consensus on some 
> > > codepoints for them, I'll support that.
> > >
> > > If IETF recommends how and which applications to use these 
> > > classes/codepoints, that's again agreeable. I don't think, that by 
> > > now requiring a specific application to carry a
> specific DSCP makes sense, apart
> > > from few exceptions (like VoIP payload,
> network management traffic or Best
> > > Effort traffic).
> > > IETF needs consensus to do that.
> > > Note that the number of AF classes and
> codepoints are troublesome. Too many
> > > with too little explanation how to use them, nothing is aligned 
> > > with user demand. EF/VoIP payload and network
> management are examples how to proceed:
> > > just specify what's required, no extras.
> > >
> > >
> > > Then regarding tunnels and header compression Yes, that's smart 
> > > and there may be more use cases than gaming. I'm a
> backbone engineer however and your
> > > proposal is rather application specific. What I can do is ask some 
> > > colleagues on their view. But there's no
> guarantee, that they will respond.
> > >
> > > Some initial thoughts:
> > > To me a key point seems to be what can be
> reached at the bottleneck. There
> > > the compression should save bandwidth with little cost and no 
> > > negative service impact. Any kind of shared access
> from which traffic is transmitted
> > > to the same destination seems to be relevant. The 
> > > application/tunnel awareness of network elements may not be
> feasible, a network terminal at a
> > > UNI may be able to handle that, or any
> service specific device in a network.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > >
> > > -----Original Message-----
> > > From: Jose Saldana 
> > > Sent: Thursday, April 05, 2012 11:29 AM
> > > To: Geib, Rüdiger
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Ruediger,
> > >
> > > I have read your message about
> draft-polk-tsvwg-rfc4594-update. As you may
> > > know, I presented another draft in Paris
> (draft-saldana-tsvwg-tcmtf-02), and
> > > after talking to James, I thought that the
> idea of standardizing the traffic
> > > classification fits well with my proposal. 
> I would like to know your opinion
> > > about it, if possible.
> > >
> > > The idea is to use tunnels in order to compress and multiplex 
> > > real-time traffic flows. Since these flows tend to
> use very small packets, they have
> > > very bad efficiency. So perhaps tunnels could be used in order to 
> > > group these flows. The drawback is that they add small delays, 
> > > i.e. the waiting time in the multiplexer. So another use is to 
> > > provide flexibility: if you are a game provider, you may over 
> > > provision
> your network in order to be able
> > > to manage traffic peaks. But perhaps using
> this, you may be able to have a
> > > smaller network, and use compression when
> necessary (rush hour, first days
> > > after releasing a new game, etc). When traffic is small, you do 
> > > not multiplex, in order to reduce latency.
> > >
> > > So if traffic classification is a standard, everyone in the way 
> > > from the origin to the destination will handle the
> traffic with the correct priority.
> > >
> > > I attach a figure in order to clarify.
> > >
> > > Thank you,
> > >
> > > Jose
> > >
> > > PS: In
> > > 
> http://community.virginmedia.com/t5/Fibre-opt...
> of-War
> > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you 
> > > can find the history of the problems of World of
> Warcraft for Virgin Media users. The
> > > problem was caused by a modification in the traffic, and the 
> > > provider did not notice about it, so it treated the packets asbest-effort.> > >
> > > -----Mensaje original-----
> > > De: 
>  Enviado el:
> > > jueves, 05 de abril de 2012 9:49
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > you raise an interesting point:
> > >
> > > draft-polk-tsvwg-rfc4594-update suggests to standardise 
> > > application to codepoint mapping as well as codepoint to
> class properties. You observe that
> > > some games are using TCP while others use UDP, which I think is a 
> > > useful level of QoS requirement abstraction.
> There's no need to have like 25+ QoS
> > > (sub)classes, I think. But one class
> optimised to transport  "UDP" and one
> > > for "TCP" are agreeable.
> > >
> > > The feedback that I had on carrier class
> QoS usage is that there's a point
> > > in standardising class properties, and certainly not to 
> > > standardise application mappings to classes
> (recommending them may however be useful).
> > > My take would be to standardise four
> classes/properties (in brackets example
> > > usage):
> > >
> > > a) for traffic which doesn't support re-transmits, requiring 
> > > lowest delay and jitter, having limited volume and packet
> > >    size, but being loss tolerant (example usage VoIP)
> > > b) for any other traffic which doesn't support re-transmits (let's 
> > > say traffic with real time like properties, but any
> > >    packet size and possibly high volume, UDP transport, like IPTV)
> > > c) for any other traffic which supports
> re-transmits (QoS traffic using TCP,
> > > like application signalling and network management traffic)
> > > d) a default class, for any traffic
> supporting re-transmits (Best Effort) -
> > > this class may not be regarded as QoS (or as lowest CoS)
> > >
> > > What I can tell ist that many carriers and standards on QoS 
> > > support 3-4 classes, having properties as described above. It is 
> > > useful to recommend codepoints matching to these classes. 
> > > Standardising these codepoints requires agreement between those 
> > > having
> deplyed them. Straightforward for a)
> > > EF and d) 000000, probably easy for c) being used to transport 
> > > Network Management (CS 6). I'm not aware of common ground for 
> > > anything else. My favourites are:
> > >
> > > b) AF4 (GSMA supports this one, RFC4594 also)
> > > c) AF3 (MEF and GSMA support this one)
> > >
> > > Gaming from my point of view would then
> match to an AF3 or AF4 class, this
> > > may depend on the implemented application
> transport. Further details may be
> > > discussed.
> > >
> > > Everything else could be reserved, but shouldn't be recommended. 
> > > Carriers have deployed differing schemes on
> codepoints and classes. They need coding
> > > reserverves in 3 bit space (MPLS TC, IP
> Precedence and Ethernet P-Bits) as
> > > well as in DSCP space if they should converge to a standardised 
> > > codepoint/class scheme.
> > >
> > > I object to any approach standardising a
> match of classes and applications
> > > with codepoints as a requirement and I also
> object to standards leaving no
> > > spare codepoints in 3 bit or 6 bit QoS
> codepoint space (including 3 bit IP
> > > precedence).
> > >
> > > Bob Briscoe mentioned the difference between classes and queues 
> > > and above properties can be mapped to queues. If end
> to end QoS is desired, the same
> > > class properties must be negotiated end to end. The lower the 
> > > number of classes and codepoints being deployed, the
> higher the probability of getting
> > > end to end QoS. I don't support an approach requiring 8 three bit 
> > > classes and 25 or more 6 bit classes and codepoints.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > ________________________________
> > >
> > > From:   On 
> > > Behalf Of Jose Saldana
> > > Sent: Monday, April 02, 2012 12:17 PM
> > > To: James Polk
> > > Cc: 
> > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > >
> > >
> > > James,
> > >
> > >
> > >
> > > After returning home from IETF 83, I have
> been reading your draft. I find it
> > > interesting to standardize the service classes. Otherwise, if each 
> > > one classifies each traffic according to different criteria, 
> > > Diffserv becomes less useful.
> > >
> > >
> > >
> > > Regarding "Real-time interactive" service class, which refers to 
> > > online gaming (my main research field), I find it
> really interesting: online games
> > > are at least as real-time as VoIP is. In
> most cases, the gamers are a very
> > > difficult people to deal with. If the
> latency is high, they leave and never
> > > return (this statement is not mine, it can
> be corroborated in the references
> > > I put below). This has been studied by many
> research groups, with empirical
> > > tests using real gamers and adding delay, jitter, packet loss.
> > >
> > >
> > >
> > > Other question: in the draft it is said that online games use 
> > > RTP/UDP streams. This can be a little confusing. In fact, the vast 
> > > majority of online games do not use RTP, but bare UDP or even TCP. 
> > > In 
> > > http://www.cn.uni-duesseldorf.de/publications...
> > > df, the authors proposed the use of an adaptation
> of RTP in order to manage gaming
> > > traffic. But as far as I know, this approach is not used by 
> > > commercial games.
> > >
> > >
> > >
> > >
> > >
> > > A typical classification of today's games is:
> > >
> > >
> > >
> > > -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Callof> > > Duty: They use UDP
> > >
> > > -          MMORPG (Massively Multiplayer Online Role-playing Games),e.g.> > > World of Warcraft: They normally use TCP,
> even though some of them use UDP
> > >
> > > -          RTS (Real-time strategy) e.g. 
> Age of Empires: They may use TCP or
> > > UDP
> > >
> > > -          Sports games: Since there is a big variety, they have notbeen> > > deeply studied in the literature
> > >
> > >
> > >
> > > Some research papers supporting this
> classification, and also the real-time
> > > requirements of the games:
> > >
> > >
> > >
> > > First Person Shooters
> > >
> > >
> > >
> > > -          A survey of traffic models for 17 First Person Shooters canbe> > > found here. All of them use UDP
> > > http://www.discover.uottawa.ca/publications/f...
> > > -IC.pdf
> > >
> > >
> > >
> > > -          In this paper from my research 
> group, 8 FPS games were analyzed
> > > in order to compress and multiplex their traffic. Figure 5 shows 
> > > their histograms (inter-packet time and packet size). It can be 
> > > seen that they generate real-time flows, with
> characteristics very similar to VoIP (packets
> > > of 60-80 bytes every 15-40 ms):
> > > http://diec.unizar.es/~jsaldana/personal/comm....
> > > pdf
> > >
> > >
> > >
> > > -          Another paper about FPS using UDP. Section V presents some
> > > interesting conclusions about routing infrastructure.
> > > http://www.thefengs.com/wuchang/work/cstrike/...
> > >
> > >
> > >
> > > -          In this paper the network factors annoying the gamers are
> > > analyzed. There are also some calculations of the MOS. Above 150 
> > > ms the quality is bad (something similar to what happens with 
> > > VoIP) http://www.research.ibm.com/netgames2005/pape...
> > >
> > >
> > >
> > > -          In this one, a MOS model for a 
> FPS (Quake IV) is deployed. It is
> > > only based on delay and jitter, since
> packet loss has vevy little influence
> > > (for this concrete game). Delay above 140 ms produces MOS below 3 
> > > http://www.nas.ewi.tudelft.nl/publications/20...
> > >
> > >
> > >
> > > -          In this paper, it is found that 
> some FPS work properly even with
> > > 30% packet loss, whereas others stop
> working with 4%. RTT above 300 ms (150
> > > OWD) makes MOS go above 3
> > > http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
> > >
> > >
> > >
> > > MMORPGs:
> > >
> > > -          A traffic model for World of Warcraft:
> > > http://publik.tuwien.ac.at/files/pub-et_12119...
> > >
> > >
> > >
> > > -          This one presents a MOS for 
> World of Warcraft. When added delay
> > > is above 160ms, the MOS is roughly 3.:
> > > http://publik.tuwien.ac.at/files/PubDat_17020...
> > >
> > >
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Jose Saldana
> > >
> > >
> >

Jose,

I'd like to join in and also volunteer to co-author, but that
for me depends on the contents we find consensus upon. My time is
administered in Best Effort mode however...

Regards, Ruediger

-----Original Message-----
From:   On Behalf Of Jose Saldana
Sent: Friday, April 27, 2012 10:06 AM
To: 'James M. Polk'
Cc: 
Subject: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt

James,

I think it is clear that people agree with the need of rewriting RFC5127 in
conjunction with RFC4594. I also agree.

If you want, I could help you with that task. Just tell me. Next two months
I think I will have a little more available time.

Jose

-----Mensaje original-----
De:   En nombre de
James M. Polk
Enviado el: jueves, 26 de abril de 2012 23:17
Para: 
CC: 
Asunto: Re: [tsvwg] About draft-polk-tsvwg-rfc4594-update-00.txt

David

I absolutely agree with you that these two efforts (the current rewrite of
RFC4594, and the coming rewrite of RFC5127) need to be synchronized to have
either make proper sense. I also agree that the rewrite of RFC5127 is where
a smaller, aggregated set of classes for core networks. Ruediger mentioned
his worry about "folks viewing tables and just configuring based on the
tables". Clearly his concerns on that need to be addressed.

I'll work to get my initial version of the rewrite of RFC5127 in before
Vancouver.

JamesAt 07:17 PM 4/25/2012,  wrote:
>Ruediger,
>
>We may be disagreeing more about means than ends.
>
>RFC 5127's intent was to aggregate all of the classes defined in RFC
>4594 into a much smaller number of classes that would be suitable for a
>core network,  e.g., "3-4 classes and require no more than 6
>codepoints".  The net would be that a choice of considerably more
>traffic classes from RFC
>4594 would be deployable via aggregation as a suitably small number of
>classes on the wire.
>
>I believe (and I've said so to James), that RFC 5127 needs to be
>revised in concert with any work on RFC 4594 (in particular, I strongly
>oppose any revision to 4594 that ignores 5127).  I also think that RFC
>5127 is a better starting point to address the small number of classes
>use case that appears to be of interest and concern to you.
>
>Thanks,
>--David
>
> > -----Original Message-----
> > From:  
> > Sent: Tuesday, April 24, 2012 5:56 AM
> > To: Black, David
> > Cc: 
> > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> >
> > David,
> >
> > taking a formal point of view, you are probably right. These isues
> > are intertwined however.
> >
> > End to end QoS will certainly not result from continuing to act like
> > almost all standards bodies did so far: as there's a lot flexibility
> > and little non-ambiguous guidance, anything is customised.
> >
> > I don't regard the update of RFC 4594 as being helpful if the
> > expectation of the author is that even supporters of that standard
> > will only deploy a subset of the defined classes and sub classes.
> > Those standards close to deployment I know offer 3-4 classes and
> > require no more than 6 codepoints (the latter is personal judgement).
> >
> > Any standards track QoS document should only determine things seeing
> > widespread deployment.
> >
> > Some QoS classes have seen deployment. It's trickier with codepoints.
> >
> > Anything which might be useful in future or has seen an
> > informational proposal in past  should be critically reviewed and
> > remain informational or experimental.
> >
> > Any QoS class should be well defined any easy to be differentiated
> > against others.
> >
> > QoS codepoints should not identify applications.
> >
> > I also don't think that one needs to differentiate "admitted" from
> > "non-admitted" classes. In a traffic engineered DiffServ network,
> > customers get an SLA describing the worst case QoS class performance.
> > To me it doesn't matter how a carrier ensures that the SLAs are kept.
> > It only matters that they are kept.
> >
> > Regards,
> >
> > Ruediger
> >
> >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of
> > > them are ECN, and six of them are the DSCP field. So
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only
> > > experimentally assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion,
> more than 4 classes are not useful,
> > > according to current implementations.
> >
> > That's actually not appropriate for an RFC
> 4594 update - the proper place to
> > address that requirement is an update to RFC 5127, which will need
> > to be updated to be consistent with whatever is done to RFC 4594.
> >
> > Thanks,
> > --David
> >
> >
> > > -----Original Message-----
> > > From:   On
> > > Behalf Of
> > Jose
> > > Saldana
> > > Sent: Saturday, April 07, 2012 8:03 AM
> > > To: ; James M. Polk
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > I have been reading the two messages of
> Ruediger about Jame's draft. I will
> > > try to make a "status of the question" and
> then a proposal. If something is
> > > wrong, just tell me.
> > >
> > > - We have the old 8 TOS bits of the IP header. Nowadays, two of
> > > them are ECN, and six of them are the DSCP field. So
> the problem is how to use these
> > > 6 bits (64 possible values)
> > > - Network control is 11xxxx, so this uses 16 values
> > >       -11xx11 are defined in RFC 2474, and remain as only
> > > experimentally assignable/useable (this uses 4 of these 16 values)
> > > - This leaves 48 values
> > > - Best effort is 000000
> > > - The draft of James proposes 14 values for
> the DSCP field, which correspond
> > > to service classes, mapped to application categories.
> > >
> > > But Ruediger says that, in his opinion,
> more than 4 classes are not useful,
> > > according to current implementations.
> > >
> > > We can ask ourselves: which are  the key
> parameters that define how packets
> > > have to be managed in a router? I think that they are:
> > >
> > > 1) "Real-time-ness": The tolerated delay of
> the service. The jitter can be
> > > roughly included in this parameter.
> > > 2) loss tolerance: We can distinguish: TCP services are tolerant
> > > to loss, since they retransmit packets. And some UDP services are
> > > also tolerant to loss (VoIP, some games, etc)
> > >
> > > In my opinion, the "real-time-ness" is the key: it distinguishes
> > > very similar services: e.g. a video conference is different from a
> > > broadcast, since the latter permits delays of some
> seconds, whereas the first has to be
> > > interactive.
> > >
> > > So one possible solution could be:
> > >
> > > - Using the first two bits in order to
> define 4 classes, taking into account
> > > the existing implementations. They can be
> the 4 classes of Fig. 1 of James'
> > > draft, or the ones proposed by Ruediger.
> > >       00xxxx  best effort
> > >       01xxxx data
> > >       10xxxx media oriented
> > >       11xxxx control
> > >
> > > - With the other 4 bits, something should be done. My proposal:
> > >       - If the third bit is "1", then the
> other three bits include a value
> > > defining the "real-time-ness" of the flow. So we have 8 levels of
> > > real-time-ness. Some examples:
> > >               - 10-1-111 would be a  media-oriented (10) and very
> > > real-time flow, as VoIP or a game
> > >               - 10-0-xxx would be a media-oriented flow for which
> > > the real-time-ness is not defined
> > >               - 10-1-010 could be a media-oriented flow with
> > > medium delay requirements, as multimedia conferencing
> > >               - 10-1-000 would be a media-oriented flow with no
> > > very hard delay requirements, as multimedia streaming
> > >               - 00-xxxx would be best-effort
> > >               -01-1-111 would be very low-latency data
> > >               -01-1-000 would be low-priority data
> > >
> > > One advantage of this is that some routers may only take into
> > > account the first two bits, and others would use all of them.
> > >
> > > The new RFC could suggest or define
> different values of real-time-ness for
> > > each application. So the applications should be ordered depending
> > > of the maximum tolerated delay.
> > >
> > > Ok. This is only an idea. Perhaps it does not make sense. Just tellme.> > > Regards,
> > >
> > > Jose
> > >
> > > -----Mensaje original-----
> > > De:  
> > > Enviado el: jueves, 05 de abril de 2012 12:23
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > regarding QoS, I'm happy to agree on 4
> standard classes with properties as
> > > mentioned in my last email. If there's consensus on some
> > > codepoints for them, I'll support that.
> > >
> > > If IETF recommends how and which applications to use these
> > > classes/codepoints, that's again agreeable. I don't think, that by
> > > now requiring a specific application to carry a
> specific DSCP makes sense, apart
> > > from few exceptions (like VoIP payload,
> network management traffic or Best
> > > Effort traffic).
> > > IETF needs consensus to do that.
> > > Note that the number of AF classes and
> codepoints are troublesome. Too many
> > > with too little explanation how to use them, nothing is aligned
> > > with user demand. EF/VoIP payload and network
> management are examples how to proceed:
> > > just specify what's required, no extras.
> > >
> > >
> > > Then regarding tunnels and header compression Yes, that's smart
> > > and there may be more use cases than gaming. I'm a
> backbone engineer however and your
> > > proposal is rather application specific. What I can do is ask some
> > > colleagues on their view. But there's no
> guarantee, that they will respond.
> > >
> > > Some initial thoughts:
> > > To me a key point seems to be what can be
> reached at the bottleneck. There
> > > the compression should save bandwidth with little cost and no
> > > negative service impact. Any kind of shared access
> from which traffic is transmitted
> > > to the same destination seems to be relevant. The
> > > application/tunnel awareness of network elements may not be
> feasible, a network terminal at a
> > > UNI may be able to handle that, or any
> service specific device in a network.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > >
> > > -----Original Message-----
> > > From: Jose Saldana 
> > > Sent: Thursday, April 05, 2012 11:29 AM
> > > To: Geib, Rüdiger
> > > Cc: 
> > > Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Ruediger,
> > >
> > > I have read your message about
> draft-polk-tsvwg-rfc4594-update. As you may
> > > know, I presented another draft in Paris
> (draft-saldana-tsvwg-tcmtf-02), and
> > > after talking to James, I thought that the
> idea of standardizing the traffic
> > > classification fits well with my proposal.
> I would like to know your opinion
> > > about it, if possible.
> > >
> > > The idea is to use tunnels in order to compress and multiplex
> > > real-time traffic flows. Since these flows tend to
> use very small packets, they have
> > > very bad efficiency. So perhaps tunnels could be used in order to
> > > group these flows. The drawback is that they add small delays,
> > > i.e. the waiting time in the multiplexer. So another use is to
> > > provide flexibility: if you are a game provider, you may over
> > > provision
> your network in order to be able
> > > to manage traffic peaks. But perhaps using
> this, you may be able to have a
> > > smaller network, and use compression when
> necessary (rush hour, first days
> > > after releasing a new game, etc). When traffic is small, you do
> > > not multiplex, in order to reduce latency.
> > >
> > > So if traffic classification is a standard, everyone in the way
> > > from the origin to the destination will handle the
> traffic with the correct priority.
> > >
> > > I attach a figure in order to clarify.
> > >
> > > Thank you,
> > >
> > > Jose
> > >
> > > PS: In
> > >
> http://community.virginmedia.com/t5/Fibre-opt...
> of-War
> > > craft-high-latency-issues-with-virgin-media-users/td-p/44498 you
> > > can find the history of the problems of World of
> Warcraft for Virgin Media users. The
> > > problem was caused by a modification in the traffic, and the
> > > provider did not notice about it, so it treated the packets asbest-effort.> > >
> > > -----Mensaje original-----
> > > De: 
>  Enviado el:
> > > jueves, 05 de abril de 2012 9:49
> > > Para: 
> > > CC: 
> > > Asunto: RE: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > > Jose,
> > >
> > > you raise an interesting point:
> > >
> > > draft-polk-tsvwg-rfc4594-update suggests to standardise
> > > application to codepoint mapping as well as codepoint to
> class properties. You observe that
> > > some games are using TCP while others use UDP, which I think is a
> > > useful level of QoS requirement abstraction.
> There's no need to have like 25+ QoS
> > > (sub)classes, I think. But one class
> optimised to transport  "UDP" and one
> > > for "TCP" are agreeable.
> > >
> > > The feedback that I had on carrier class
> QoS usage is that there's a point
> > > in standardising class properties, and certainly not to
> > > standardise application mappings to classes
> (recommending them may however be useful).
> > > My take would be to standardise four
> classes/properties (in brackets example
> > > usage):
> > >
> > > a) for traffic which doesn't support re-transmits, requiring
> > > lowest delay and jitter, having limited volume and packet
> > >    size, but being loss tolerant (example usage VoIP)
> > > b) for any other traffic which doesn't support re-transmits (let's
> > > say traffic with real time like properties, but any
> > >    packet size and possibly high volume, UDP transport, like IPTV)
> > > c) for any other traffic which supports
> re-transmits (QoS traffic using TCP,
> > > like application signalling and network management traffic)
> > > d) a default class, for any traffic
> supporting re-transmits (Best Effort) -
> > > this class may not be regarded as QoS (or as lowest CoS)
> > >
> > > What I can tell ist that many carriers and standards on QoS
> > > support 3-4 classes, having properties as described above. It is
> > > useful to recommend codepoints matching to these classes.
> > > Standardising these codepoints requires agreement between those
> > > having
> deplyed them. Straightforward for a)
> > > EF and d) 000000, probably easy for c) being used to transport
> > > Network Management (CS 6). I'm not aware of common ground for
> > > anything else. My favourites are:
> > >
> > > b) AF4 (GSMA supports this one, RFC4594 also)
> > > c) AF3 (MEF and GSMA support this one)
> > >
> > > Gaming from my point of view would then
> match to an AF3 or AF4 class, this
> > > may depend on the implemented application
> transport. Further details may be
> > > discussed.
> > >
> > > Everything else could be reserved, but shouldn't be recommended.
> > > Carriers have deployed differing schemes on
> codepoints and classes. They need coding
> > > reserverves in 3 bit space (MPLS TC, IP
> Precedence and Ethernet P-Bits) as
> > > well as in DSCP space if they should converge to a standardised
> > > codepoint/class scheme.
> > >
> > > I object to any approach standardising a
> match of classes and applications
> > > with codepoints as a requirement and I also
> object to standards leaving no
> > > spare codepoints in 3 bit or 6 bit QoS
> codepoint space (including 3 bit IP
> > > precedence).
> > >
> > > Bob Briscoe mentioned the difference between classes and queues
> > > and above properties can be mapped to queues. If end
> to end QoS is desired, the same
> > > class properties must be negotiated end to end. The lower the
> > > number of classes and codepoints being deployed, the
> higher the probability of getting
> > > end to end QoS. I don't support an approach requiring 8 three bit
> > > classes and 25 or more 6 bit classes and codepoints.
> > >
> > > Regards,
> > >
> > > Ruediger
> > >
> > > ________________________________
> > >
> > > From:   On
> > > Behalf Of Jose Saldana
> > > Sent: Monday, April 02, 2012 12:17 PM
> > > To: James Polk
> > > Cc: 
> > > Subject: About draft-polk-tsvwg-rfc4594-update-00.txt
> > >
> > >
> > >
> > > James,
> > >
> > >
> > >
> > > After returning home from IETF 83, I have
> been reading your draft. I find it
> > > interesting to standardize the service classes. Otherwise, if each
> > > one classifies each traffic according to different criteria,
> > > Diffserv becomes less useful.
> > >
> > >
> > >
> > > Regarding "Real-time interactive" service class, which refers to
> > > online gaming (my main research field), I find it
> really interesting: online games
> > > are at least as real-time as VoIP is. In
> most cases, the gamers are a very
> > > difficult people to deal with. If the
> latency is high, they leave and never
> > > return (this statement is not mine, it can
> be corroborated in the references
> > > I put below). This has been studied by many
> research groups, with empirical
> > > tests using real gamers and adding delay, jitter, packet loss.
> > >
> > >
> > >
> > > Other question: in the draft it is said that online games use
> > > RTP/UDP streams. This can be a little confusing. In fact, the vast
> > > majority of online games do not use RTP, but bare UDP or even TCP.
> > > In
> > > http://www.cn.uni-duesseldorf.de/publications...
> > > df, the authors proposed the use of an adaptation
> of RTP in order to manage gaming
> > > traffic. But as far as I know, this approach is not used by
> > > commercial games.
> > >
> > >
> > >
> > >
> > >
> > > A typical classification of today's games is:
> > >
> > >
> > >
> > > -          FPS (First Person Shooters) e.g. Counter Strike, Halo, Callof> > > Duty: They use UDP
> > >
> > > -          MMORPG (Massively Multiplayer Online Role-playing Games),e.g.> > > World of Warcraft: They normally use TCP,
> even though some of them use UDP
> > >
> > > -          RTS (Real-time strategy) e.g.
> Age of Empires: They may use TCP or
> > > UDP
> > >
> > > -          Sports games: Since there is a big variety, they have notbeen> > > deeply studied in the literature
> > >
> > >
> > >
> > > Some research papers supporting this
> classification, and also the real-time
> > > requirements of the games:
> > >
> > >
> > >
> > > First Person Shooters
> > >
> > >
> > >
> > > -          A survey of traffic models for 17 First Person Shooters canbe> > > found here. All of them use UDP
> > > http://www.discover.uottawa.ca/publications/f...
> > > -IC.pdf
> > >
> > >
> > >
> > > -          In this paper from my research
> group, 8 FPS games were analyzed
> > > in order to compress and multiplex their traffic. Figure 5 shows
> > > their histograms (inter-packet time and packet size). It can be
> > > seen that they generate real-time flows, with
> characteristics very similar to VoIP (packets
> > > of 60-80 bytes every 15-40 ms):
> > > http://diec.unizar.es/~jsaldana/personal/comm....
> > > pdf
> > >
> > >
> > >
> > > -          Another paper about FPS using UDP. Section V presents some
> > > interesting conclusions about routing infrastructure.
> > > http://www.thefengs.com/wuchang/work/cstrike/...
> > >
> > >
> > >
> > > -          In this paper the network factors annoying the gamers are
> > > analyzed. There are also some calculations of the MOS. Above 150
> > > ms the quality is bad (something similar to what happens with
> > > VoIP) http://www.research.ibm.com/netgames2005/pape...
> > >
> > >
> > >
> > > -          In this one, a MOS model for a
> FPS (Quake IV) is deployed. It is
> > > only based on delay and jitter, since
> packet loss has vevy little influence
> > > (for this concrete game). Delay above 140 ms produces MOS below 3
> > > http://www.nas.ewi.tudelft.nl/publications/20...
> > >
> > >
> > >
> > > -          In this paper, it is found that
> some FPS work properly even with
> > > 30% packet loss, whereas others stop
> working with 4%. RTT above 300 ms (150
> > > OWD) makes MOS go above 3
> > > http://caia.swin.edu.au/pubs/ATNAC04/zander-a...
> > >
> > >
> > >
> > > MMORPGs:
> > >
> > > -          A traffic model for World of Warcraft:
> > > http://publik.tuwien.ac.at/files/pub-et_12119...
> > >
> > >
> > >
> > > -          This one presents a MOS for
> World of Warcraft. When added delay
> > > is above 160ms, the MOS is roughly 3.:
> > > http://publik.tuwien.ac.at/files/PubDat_17020...
> > >
> > >
> > >
> > > Best regards,
> > >
> > >
> > >
> > > Jose Saldana
> > >
> > >
> >

Jose,

thanks, part of your proposal isn't that far from the current deployment.

IP offers 6 bits to encode QoS classes, while MPLS and Ethernet only offer three.
The commodity solution mapping IP QoS classes to MPLS or Ethernet is to copy the
three most significant bits of the DSCP into the three bit QoS codepoint of
Ethernet/MPLS (you proposed to use 2 bits).
These three most significant bits are the so called IP-Precedence (RFC791).

Making this copy mechanism a standard behaviour is a feature I'd support. It's
simple, straightforward an widely deployed. Also DiffServ respects the precedence,
EF has IP Prec 5, AF4 has IP Prec 4 and so on.

All in all now, there are 8 possible codepoints. I suggest to standardise 4
classes. Some may use sub-classes with own codepoints. Further, a reserve
of codepoints should be left for experiments and for provider internal use.

So on standards track I support at most 4 classes and 4 IP precedence values.

The number of IP DSCPs to be standardised should follow the usual IETF way of
dealing with things: If there's widespread deployment and more than one
interoperable solution, put things on standards track. My take of
interoperable solution here is not IETF like, as I look at this meaning
two carriers or more having deployed a class in the same way.

Starting from there you soon divide the problem into two issues:

- carrier QoS classes having similar properties.
- codepoints identifying these classes.

Classes and codepoints I like:

Class                   IP Prec, TC, P-Bits     Example Use
UDP short packets       5                               Telephony
UDP any         4                               Streaming, IPTV, Gaming
TCP any         3                               Data, Signaling, 3. party netmgmt
Default         0                               Best Effort

IP prec 6 should be reserved for network management traffic. I don't look
at this as a public class (meaning it will be mapped to another class/DSCP
at interconnection).

Sub-classes on IP level are possible, the TCP any class is a candidate (AF3).

The former should see standardisation by now. The latter is not in a good
shape and requires goodwill and allow for migration plan, if something easy to
deploy should result. End to end QoS based with well known class properties
and codepoints only results that way.

A clear cause of the problem is the high number of DSCPs and the
low degree of usage guidance of the AF classes. There's a need for two
standard AF classes and up to 5 codepoints, that's my point of view.

Compare EF: it uses a single DSCP and IP precedence and it has well
defined properties. It saw widespread deployment. EF can be produced end
to end.

I oppose any concept to standardise over 25 DSCPs or any standard
leaving no IP precedence codepoints for reserve. It doesn't matter whether
that's in a VPN or public. QoS classes and codepoints to be put on standards
track should have seen deployment and get support by more than one carrier.

Entertaining documentation on classes and codepoints without a clear demand
for usage impeded end to end QoS deployment so far.

Regards,

Ruediger


-----Original Message-----
From: Jose Saldana 
Sent: Saturday, April 07, 2012 2:03 PM
To: Geib, Rüdiger; James M. Polk
Cc: 
Subject: RE: About draft-polk-tsvwg-rfc4594-update-00.txt

I have been reading the two messages of Ruediger about Jame's draft. I will
try to make a "status of the question" and then a proposal. If something is
wrong, just tell me.

- We have the old 8 TOS bits of the IP header. Nowadays, two of them are
ECN, and six of them are the DSCP field. So the problem is how to use these
6 bits (64 possible values)
- Network control is 11xxxx, so this uses 16 values
        -11xx11 are defined in RFC 2474, and remain as only experimentally
assignable/useable (this uses 4 of these 16 values)
- This leaves 48 values
- Best effort is 000000
- The draft of James proposes 14 values for the DSCP field, which correspond
to service classes, mapped to application categories.

But Ruediger says that, in his opinion, more than 4 classes are not useful,
according to current implementations.

We can ask ourselves: which are  the key parameters that define how packets
have to be managed in a router? I think that they are:

1) "Real-time-ness": The tolerated delay of the service. The jitter can be
roughly included in this parameter.
2) loss tolerance: We can distinguish: TCP services are tolerant to loss,
since they retransmit packets. And some UDP services are also tolerant to
loss (VoIP, some games, etc)

In my opinion, the "real-time-ness" is the key: it distinguishes very
similar services: e.g. a video conference is different from a broadcast,
since the latter permits delays of some seconds, whereas the first has to be
interactive.

So one possible solution could be:

- Using the first two bits in order to define 4 classes, taking into account
the existing implementations. They can be the 4 classes of Fig. 1 of James'
draft, or the ones proposed by Ruediger.
        00xxxx  best effort
        01xxxx data
        10xxxx media oriented
        11xxxx control

- With the other 4 bits, something should be done. My proposal:
        - If the third bit is "1", then the other three bits include a value
defining the "real-time-ness" of the flow. So we have 8 levels of
real-time-ness. Some examples:
                - 10-1-111 would be a  media-oriented (10) and very
real-time flow, as VoIP or a game
                - 10-0-xxx would be a media-oriented flow for which the
real-time-ness is not defined
                - 10-1-010 could be a media-oriented flow with medium delay
requirements, as multimedia conferencing
                - 10-1-000 would be a media-oriented flow with no very hard
delay requirements, as multimedia streaming
                - 00-xxxx would be best-effort
                -01-1-111 would be very low-latency data
                -01-1-000 would be low-priority data

One advantage of this is that some routers may only take into account the
first two bits, and others would use all of them.

The new RFC could suggest or define different values of real-time-ness for
each application. So the applications should be ordered depending of the
maximum tolerated delay.

Ok. This is only an idea. Perhaps it does not make sense. Just tell me.
Regards,

Jose