Subject: About the tunnels: packets per second savings

From: "Jose Saldana" <[email-masked]>
Date: Thu, 5 Apr 2012 14:14:07 +0200

Ruediger,

Thank you for your fast response.  I will separately answer the two parts of
your email. First, this message about the tunnels. This afternoon or
tomorrow I will send to the list an idea about QoS classes, but I have to
think more before sending it.

I'm glad to hear that you consider the "tunnels" proposal interesting. There
is another issue that I discussed with Gorry in Paris: the saving in terms
of packets per second. I attach a graph of the saving in terms of this
parameter using Counter Strike. If you multiplex all the packets you have
received e.g. every 20ms, then you will send  50 pps (the inverse of the
multiplexing period). So you can save a lot of pps.

It is clear that bandwidth saving is interesting, but I have read some
papers in which a "packets per second" upper bound in the routers was
reported:

Section V.A of
W. Feng, F. Chang, W. Feng, J. Walpole: “A Traffic Characterization of
Popular On-Line Games”. IEEE/ACM Trans. Netw., pp. 488-500, 2005.
http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf

Section IV.3 of
J. Yu, I. Al-Ajarmeh. “Call Admission Control and Traffic Engineering of
VoIP”, In Proc. Second Intenational Conference on Digital
Telecommunications, IEEE ICDT 2007.
http://140.192.40.4:8001/~imad/voip/YuJ-CallAdmin.pdf

They not only talk about the bandwidth limitation of routers, but also the
packets per second limit. Gorry told me that high-end routers may not have
this problem. But low-end routers are not able to back-to-back send small
packets, due to the processing limitation.

So, do you think this saving is interesting? Since you work in the backbone,
your opinion is important for me, taking into account that I am an Academia
researcher, and sometimes we are a little far from real things. Perhaps you
may ask some of your colleagues.

Thanks,

Jose 

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

Jose,

(...) I have removed the first part of the message for clarity.

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 [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 11:29 AM
To: Geib, Rüdiger
Cc: [email-masked]
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-optic-broadband-cable/World-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 as best-effort.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] Enviado el:
jueves, 05 de abril de 2012 9:49
Para: [email-masked]
CC: [email-masked]
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: [email-masked] [mailto:[email-masked]] On Behalf Of
Jose Saldana
Sent: Monday, April 02, 2012 12:17 PM
To: James Polk
Cc: [email-masked]
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/library/Mauve2001a.pdf, 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/files/MMOG-Survey_IEEE-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/commag_nov_2011_jsaldana.pdf

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

-          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/papers/dick.pdf

-          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/2006/netgames.pdf

-          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-armitage-ATNAC2004.pdf

MMORPGs:

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

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

Best regards,

Jose Saldana

---

From: <[email-masked]>
Date: Tue, 24 Apr 2012 10:28:05 +0200

Jose,

sorry for being late with my reply. Two of my colleagues replied. Simple bandwidth
savings at the access itself would be interesting, especially in the case of shared
networks.

Your proposal is related to the "core" part of the network and as you
describe below, high end routers can deal with bigger numbers of packets per second.

That's the reason why my colleagues are not interested in working on the subject.

Regards,

Ruediger

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 2:14 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: About the tunnels: packets per second savings

Ruediger,

Section V.A of
W. Feng, F. Chang, W. Feng, J. Walpole: "A Traffic Characterization of
Popular On-Line Games". IEEE/ACM Trans. Netw., pp. 488-500, 2005.
http://www.thefengs.com/wuchang/work/cstrike/ton05_traffic.pdf

Section IV.3 of
J. Yu, I. Al-Ajarmeh. "Call Admission Control and Traffic Engineering of
VoIP", In Proc. Second Intenational Conference on Digital
Telecommunications, IEEE ICDT 2007.
http://140.192.40.4:8001/~imad/voip/YuJ-CallAdmin.pdf

Thanks,

Jose

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

Jose,

Some initial thoughts:

Regards,

Ruediger

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

Ruediger,

Thank you,

Jose

PS: In

-----Mensaje original-----

Jose,

Regards,

Ruediger

James,

First Person Shooters

MMORPGs:

Best regards,

Jose Saldana

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 24 Apr 2012 11:14:54 +0200

Ruediger,

Thanks for your response. This is good for understanding which are the best
scenarios for TCMTF.

Best regards,

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] 
Enviado el: martes, 24 de abril de 2012 10:28
Para: [email-masked]
CC: [email-masked]
Asunto: RE: About the tunnels: packets per second savings

Jose,

sorry for being late with my reply. Two of my colleagues replied. Simple
bandwidth savings at the access itself would be interesting, especially in
the case of shared networks.

Your proposal is related to the "core" part of the network and as you
describe below, high end routers can deal with bigger numbers of packets per
second.

That's the reason why my colleagues are not interested in working on the
subject.

Regards,

Ruediger

-----Original Message-----
From: Jose Saldana [mailto:[email-masked]]
Sent: Thursday, April 05, 2012 2:14 PM
To: Geib, Rüdiger
Cc: [email-masked]
Subject: About the tunnels: packets per second savings

Ruediger,

Section V.A of

Section IV.3 of

Thanks,

Jose

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

Jose,

Some initial thoughts:

Regards,

Ruediger

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

Ruediger,

Thank you,

Jose

PS: In

-----Mensaje original-----

Jose,

Regards,

Ruediger

James,

First Person Shooters

MMORPGs:

Best regards,

Jose Saldana