Re: [tcmtf] Answers to possible questions in the BOF

["Jose Saldana" <[e-mail]>]

You are right, Michael.

 

Sometimes you can prevent the stall. For example, in the release of a new
online game, you can predict that everybody will be waiting in front of the
computer at 0:00 AM in order to be the first ones playing: see what happened
some months ago when “Diablo III” was released (the “launch-day crash”):

 
<http://www.nbcnews.com/technology/blizzard-apologizes-diablo-disaster-77807
2>
http://www.nbcnews.com/technology/blizzard-apologizes-diablo-disaster-778072

 

But other times you cannot predict it. For example, think about the amount
of whatsapp messages sent whenever a soccer team scores a goal.

 

So I think we should definitely think about dynamically using TCM-TF,
integrating different ways for detecting congestion and traffic rushes. In
fact, this is already included in the draft charter, but only as a
possibility for re-chartering, once TCM-TF is well defined (number 9
<http://www.ietf.org/mail-archive/web/tcmtf/current/msg00286.html>
http://www.ietf.org/mail-archive/web/tcmtf/current/msg00286.html):

 

“dynamically applying TCMTF: a higher entity in charge of deciding when and
where, applying or not 

TCMTF, and what kind of TCMTF, and what multiplexing period. Additional
methods for estimating delay 

would also be required.”

 

Thanks!

 

Jose

 

De: Michael Ramalho (mramalho) [mailto:[e-mail]] 
Enviado el: miércoles, 03 de julio de 2013 14:42
Para: [e-mail]; [e-mail]
Asunto: RE: [tcmtf] Answers to possible questions in the BOF

 

Jose .. you say: 

 

“I don’t have to over-dimension my network. When a traffic rush is detected,
I can get advantage of this tradeoff, compressing traffic up to 50 or 60%,
at the cost of a small added latency. The service would work a bit more
slowly, but it would at least work.”

 

You may have actually over-stated the cost. For such a rush, many of the
http sessions during “the rush” would stall (go into slow-start). For that
subset you may have prevented the stall! Thus while most of the sessions may
incur the cost of “small added latency” (of ~40ms or less), some of the
sessions avoided stalling entirely!

 

I hate it when a web page tries to fetch 100 things … and the http get of
ONE of those things stalls … and prevents me from using site as intended.
Preventing stalls is a good thing.

 

Also on the “traffic rush” issue … TCMTF can be used dynamically to lessen
bufferbloat (effectively lowering the amount of buffer used on highly
buffered links) on a particular egress link. That is, if you see your egress
buffer growing, you might try to compress traffic toward it when you can.
That could even lessen the delay for all users at such a sports event (lots
of small packets representing updates to game statistics).

 

Michael Ramalho

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
Jose Saldana
Sent: Wednesday, July 03, 2013 6:44 AM
To: [e-mail]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

 

Question 5: Is there a significant amount of traffic of services based on
small packets? Is it interesting to compress it? Why?

 

Answer (some ideas):

 

Although the vast majority of Internet traffic corresponds to big packets
(file transfers, video downloads), this best-effort traffic does not present
tight delay requirements.

 

However, many of the services using small packets have stringent delay
requirements, so the network has to deliver them faster. And this share of
the traffic is really critical for network operators: if I wait 5 seconds to
watch a video, it is not a problem. However, if my VoIP call or my online
game have a latency of 100ms, it can be a serious problem.

 

In addition, some of these small-packet services are present on certain
network segments where bandwidth may be scarce (residential access,
aggregation networks, satellite links), or a pps limit exists. In the
context of mobile networks:

 

- New VoIP services are using data links instead of establishing traditional
voice calls (e.g., viber)

- Online games are being played with tablets and smartphones:
<http://www.juniperresearch.com/viewpressrelease.php?id=534&pr=364>
http://www.juniperresearch.com/viewpressrelease.php?id=534&pr=364

- Internet of Things: many “things” will send small packets with a certain
frequency

- New traffic patterns: “Major changes in traffic characteristics are the
increases in small packets, short connections, signaling and data traffic,
and abnormal traffic. For Universal Mobile Telecommunications System (UTMS)
networks in idle status, all these changes lead to sharp increases on
signaling and other system resource load. They also bring severe threat on
network performance, and affect application data throughput capability and
network profitability in the long run.” (Huawei Smartphone Solutions White
Paper).

 

The mobility of the users has some other implications: The network may
experience a “traffic rush” in certain places or moments (e.g., a sports
event, the World release of a new game), so TCM-TF would provide a certain
degree of flexibility (a tradeoff): I don’t have to over-dimension my
network. When a traffic rush is detected, I can get advantage of this
tradeoff, compressing traffic up to 50 or 60%, at the cost of a small added
latency. The service would work a bit more slowly, but it would at least
work.

 

In addition, if I only “awake” TCM-TF optimization when I have a lot of
traffic, then I will add a really tiny latency, since I will have lots of
packets to multiplex, and in 5ms I may be able to create an MTU-sized
multiplexed packet.

 

Any other ideas?

 

Jose

 

De: [e-mail] [mailto:[e-mail]] En nombre de Jose
Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: [e-mail]
Asunto: [tcmtf] Answers to possible questions in the BOF

 

I would like to start a thread about possible questions people may ask in
the BOF. Obviously, we also need answers, so we should cooperate.

 

This is different from the “questions to ask in the BOF”. This will be
discussed separately.

 

Thanks!

 

Jose