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

["Michael Ramalho (mramalho)" <[e-mail]>]

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
- 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]> [mailto:[e-mail]] En nombre de Jose Saldana
Enviado el: lunes, 24 de junio de 2013 13:00
Para: [e-mail]<mailto:[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