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

From: "Jose Saldana" <[email-masked]>
Date: Mon, 24 Jun 2013 13:00:05 +0200

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

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 24 Jun 2013 13:20:55 +0200

Question: Why Transport Area?

Answer:

There are three possibilities: RAI, Internet and Transport Area. These are
some of the protocols to be used:

L2TPv3: Internet Area (RFC 3931, March 2005)

PPPMux: Internet Area (RFC 3153, August 2001)

ECRTP: RAI Area (RFC 3545, July 2003)

ROHC: Transport Area, although it can also compress RTP (RFC 5795, March
2010)

1) RAI

TCM-TF is about real-time services. In fact, it would update RFC4170, which
was developed within the RAI Area.

However, we are proposing to go towards a more generic scheme. RAI area is
mainly focused on RTP, and TCM-TF only considers RTP as one of the
possibilities. Bare UDP or even TCP flows can be compressed, multiplexed and
tunneled.

2) Internet Area or Transport Area?

RFC 1122 defines the layers as:

- Transport Layer: "The transport layer provides *end-to-end* communication
services for applications".

- Internet Layer: "All Internet transport protocols use the Internet
Protocol (IP) to carry data from source host to destination host. IP is a
connectionless or datagram internetwork service, providing *no end-to-end*
delivery guarantees".

TCMTF is an *end-to-end* solution, requiring some knowledge of the traffic
to multiplex, and a synchronization of the context on both sides.

So it is clear that it fits in the Transport Area.

Jose

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

Thanks!

Jose

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 24 Jun 2013 13:31:10 +0200

Question 2: Why creating a Working Group? Why not doing this inside the
tsvwg?

Answer:

This was our first idea, one year ago. But it has become clear that a
specific WG is required for this. 

This in it is something a separate WG should be created to handle, and not
something to try to do inside the TSVWG, since there are already a handful
of things TSVWG is wrestling with, and it creates too much "context
switching" to have a lot of unrelated topics under work there.

The question is that the TSVWG group has a lot of interesting things now,
and it would be better to discuss TCMTF separately.

Any comments?

Jose

Thanks!

Jose

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Mon, 24 Jun 2013 16:19:17 +0200

I agree with Jose about the group TSVWG has a lot of interesting things 
now, and it would be best to discuss TCMTF separately.
Julián

El 24/06/2013 13:31, Jose Saldana escribió:
> TSVWG group has a lot of interesting things now, and it would be 
> better to discuss TCMTF separately.

---

From: "Jose Saldana" <[email-masked]>
Date: Tue, 25 Jun 2013 10:26:42 +0200

Question 3: You are talking about real-time services (VoIP, online games,
remote desktop). *Why adding a new (multiplexing) delay?* Would it harm the
user's experience with the service?

Answer

1) We have had that question in mind from the very beginning. We want to
save bandwidth and pps, but always preserving subjective quality. In fact, a
specific draft has been written including a set of recommendations of the
maximum delays that can be tolerated by users of different services. The
draft includes references to studies where subjective quality has been
evaluated with real people.

2) In addition, our idea is that TCM-TF can be something to be used
dynamically when required. Some examples:

- I am in the rush hour and I notice a lot of traffic in my network. In
order to avoid the collapse, I optimize traffic. I add a small delay, but
the bandwidth savings can make it possible that the service still works.

- I am an online games provider and I am releasing a new title. The first
days, a lot of people will want to play. So, how can I dimension my network?
Should I dimension it for the worst case?

TCM-TF provides flexibility: there is a tradeoff: a small additional delay
as the price for maintaining the service. It should be taken into account
that for certain services the bandwidth savings are 50 or even 60%.

3) If I have a high number of flows, I can achieve significant bandwidth
savings while adding small delays. Some examples:

- 10 VoIP flows G729 can be optimized including one packet from each flow
(average additional delay 10ms) and 50% of bandwidth can be saved

- if I have 100 flows of a TCP-based online game, I can achieve 45%
bandwidth saving with a multiplexing period of 30 ms (average additional
delay 15ms)

4) TCM-TF is not only for real-time services. Other small-packet services
can be optimized, and in this case the additional delay would not be
significant.

Any other thoughts?

Jose

Thanks!

Jose

---

From: Julián Fernández-Navajas <[email-masked]>
Date: Wed, 26 Jun 2013 11:23:52 +0200

Another answer for this question is that if you reduce the pps in the 
network it is possible that the delay also reduces, because the nodes 
have minor charge of work.
Julián

El 25/06/2013 10:26, Jose Saldana escribió:
>
> Question 3: You are talking about real-time services (VoIP, online 
> games, remote desktop). **Why adding a new (multiplexing) delay?** 
> Would it harm the user's experience with the service?
>
> Answer
>
> 1) We have had that question in mind from the very beginning. We want 
> to save bandwidth and pps, but always preserving subjective quality. 
> In fact, a specific draft has been written including a set of 
> recommendations of the maximum delays that can be tolerated by users 
> of different services. The draft includes references to studies where 
> subjective quality has been evaluated with real people.
>
> - I am in the rush hour and I notice a lot of traffic in my network. 
> In order to avoid the collapse, I optimize traffic. I add a small 
> delay, but the bandwidth savings can make it possible that the service 
> still works.
>
> - I am an online games provider and I am releasing a new title. The 
> first days, a lot of people will want to play. So, how can I dimension 
> my network? Should I dimension it for the worst case?
>
> TCM-TF provides flexibility: there is a tradeoff: a small additional 
> delay as the price for maintaining the service. It should be taken 
> into account that for certain services the bandwidth savings are 50 or 
> even 60%.
>
> 3) If I have a high number of flows, I can achieve significant 
> bandwidth savings while adding small delays. Some examples:
>
> - 10 VoIP flows G729 can be optimized including one packet from each 
> flow (average additional delay 10ms) and 50% of bandwidth can be saved
>
> bandwidth saving with a multiplexing period of 30 ms (average 
> additional delay 15ms)
>
> 4) TCM-TF is not only for real-time services. Other small-packet 
> services can be optimized, and in this case the additional delay would 
> not be significant.
>
> Any other thoughts?
>
> Jose
>
> *De:[email-masked] [mailto:[email-masked]] *En nombre 
> de *Jose Saldana
> *Enviado el:* lunes, 24 de junio de 2013 13:00
> *Para:* [email-masked]
> *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.
>
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: Mirko Sužnjević <[email-masked]>
Date: Wed, 26 Jun 2013 09:35:47 +0000

Hello all,
Here i have just a small addition:
By using TCM-TF we aim maintain the QoE of the service, or at least minimize the degradation.

1)      Recommended limits of multiplexing period are given in order not do significantly degrade the service (on applicable applications and studies we aimed at MOS over 4).

2)      1st example of a dynamic scenarios TCMTF is actually reducing latency by preventing congestion (rush hour scenario)

2)      2nd example of the launch of the game scenario TCM-TF provides significant savings, and increase of the QoE as service unavailability is much much more QoE degrading for gamers than slight latency increase
Also i would emphasize that the added delay is very minimal on links with high packet rate, and that the maximal introduced delay can be controlled with the multiplexing period depending on how much tradeoff is needed or allowed.
Cheers!
Mirko
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jose Saldana
Sent: Tuesday, June 25, 2013 10:27 AM
To: [email-masked]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

Question 3: You are talking about real-time services (VoIP, online games, remote desktop). *Why adding a new (multiplexing) delay?* Would it harm the user’s experience with the service?

Answer

1) We have had that question in mind from the very beginning. We want to save bandwidth and pps, but always preserving subjective quality. In fact, a specific draft has been written including a set of recommendations of the maximum delays that can be tolerated by users of different services. The draft includes references to studies where subjective quality has been evaluated with real people.

2) In addition, our idea is that TCM-TF can be something to be used dynamically when required. Some examples:

- I am in the rush hour and I notice a lot of traffic in my network. In order to avoid the collapse, I optimize traffic. I add a small delay, but the bandwidth savings can make it possible that the service still works.

- I am an online games provider and I am releasing a new title. The first days, a lot of people will want to play. So, how can I dimension my network? Should I dimension it for the worst case?

TCM-TF provides flexibility: there is a tradeoff: a small additional delay as the price for maintaining the service. It should be taken into account that for certain services the bandwidth savings are 50 or even 60%.

3) If I have a high number of flows, I can achieve significant bandwidth savings while adding small delays. Some examples:
- 10 VoIP flows G729 can be optimized including one packet from each flow (average additional delay 10ms) and 50% of bandwidth can be saved
- if I have 100 flows of a TCP-based online game, I can achieve 45% bandwidth saving with a multiplexing period of 30 ms (average additional delay 15ms)

4) TCM-TF is not only for real-time services. Other small-packet services can be optimized, and in this case the additional delay would not be significant.

Any other thoughts?

Jose

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

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 26 Jun 2013 12:49:17 +0200

Question 4: Is TCM-TF interesting for the Industry? Should the IETF
standardize this?

Answer:

1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP traffic. So if
RFC4170 was interesting, why not updating it?

2) TCM-TF can be useful in order to save bandwidth in many cases:

- Aggregation network of *network operators*: We are saving bandwidth by
optimizing and putting together traffic flows. Is this interesting for a
network operator? What about overprovisioning? The idea is that there are
places and moments in which a number of flows based on small packets are in
the same place and at the same moment. Then, TCM-TF can be applied in order
to provide flexibility. We are not optimizing the overall Internet traffic,
we are optimizing specific flows with very tight delay requirements, which
network operators have to take care of in a special way.

www.huawei.com/ilink/en/download/HW_193034

- *End to end* optimization: Nowadays, many appliances are used to connect
remote offices of the same company (creating a VPN). So if a tunnel exists,
why not optimizing this traffic when possible? We would save bandwidth in
the access network, where it can be scarce.

- Wireless and satellite scenarios.

Any other thoughts? Any other scenarios in mind? Potential beneficiaries? 

Jose

Thanks!

Jose

---

From: DAVID FLOREZ RODRIGUEZ <[email-masked]>
Date: Wed, 26 Jun 2013 13:13:00 +0000

Howdy,

Regarding the industry, specially operators' interest. I think that part of the case relies on the assumption that TCMT could help operators to cope with surges of traffic, either local or global.

The case of traffic surges would have also the advantage that the interactivity requirement could be relaxed, since there would be more packets to process in the first time, and most importantly, that the application point of the algorithms could be shallow or deep in the network, according to traffic status.

Best Regards,

------------------------------------------------------------------

David Flórez Rodríguez
Phome: 34+913129618
Backup Phone: 34+913128842
e-mail: [email-masked]<mailto:[email-masked]>
Network Optimisation and Dynamisation Initiative
Telefonica I+D

------------------------------------------------------------------

As if my life were shaven
and fitted to a frame
and could not breathe without a key
and 'twas like midnight, some,
when everything that ticked has stopped
and space stares all around
or grisly frost, first autumn morns,
repeal the beating ground
but most like chaos, stopless, cool
without a chance or spar
or even a report of land
to justify dispair

              Emily Dickinson

-----------------------------------------------------------------

De: [email-masked] [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: miércoles, 26 de junio de 2013 12:49
Para: [email-masked]
Asunto: Re: [tcmtf] Answers to possible questions in the BOF

Question 4: Is TCM-TF interesting for the Industry? Should the IETF standardize this?

Answer:

1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP traffic. So if RFC4170 was interesting, why not updating it?

- Aggregation network of *network operators*: We are saving bandwidth by optimizing and putting together traffic flows. Is this interesting for a network operator? What about overprovisioning? The idea is that there are places and moments in which a number of flows based on small packets are in the same place and at the same moment. Then, TCM-TF can be applied in order to provide flexibility. We are not optimizing the overall Internet traffic, we are optimizing specific flows with very tight delay requirements, which network operators have to take care of in a special way.
www.huawei.com/ilink/en/download/HW_193034<http://www.huawei.com/ilink/en/download/HW_193034>

- *End to end* optimization: Nowadays, many appliances are used to connect remote offices of the same company (creating a VPN). So if a tunnel exists, why not optimizing this traffic when possible? We would save bandwidth in the access network, where it can be scarce.

Jose

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

Thanks!

Jose

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Dan Wing <[email-masked]>
Date: Wed, 26 Jun 2013 13:13:46 -0700

> - Wireless and satellite scenarios.

"Cisco adds IP multiplexing to mobile satellite package", April 2012, http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.html

> Any other thoughts? Any other scenarios in mind? Potential beneficiaries?

Some networks, today, use cRTP (RFC2508) on their access links.  This gives bandwidth savings on the access link, but consumes considerable CPU horsepower on the aggregation router (to perform cRTP), but provides no bandwidth savings across the network core.  If, instead, the bandwidth could be saved on the access link, across the core, and on the far-end access link -- all without the CPU impact on the aggregation router -- it is a considerable win.

-d

---

From: <[email-masked]>
Date: Thu, 27 Jun 2013 09:53:43 +0000

Hi Dan,

Would it be possible to have more info on this CISCO product?

Actually, nowadays satellite technology already implements multiplexing capabilities to better exploit the satellite capacity. In this respect it would be interesting to understand the interaction of the CISCO multiplexing-enabled router and the functions already available in satellite terminals.

Thanks in advance

Regards,

Tomaso

------------------------
Deutsches Zentrum für Luft- und Raumfahrt (DLR)
German Aerospace Center
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany
Tomaso de Cola, Ph.D.
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked]<mailto:[email-masked]>
http://www.dlr.de/kn/institut/abteilungen/san

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan Wing
Sent: Wednesday, June 26, 2013 10:14 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [tcmtf] Answers to possible questions in the BOF

On Jun 26, 2013, at 3:49 AM, Jose Saldana <[email-masked]<mailto:[email-masked]>> wrote:

Answer:

-d

Jose

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

Thanks!

Jose

_______________________________________________
tcmtf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcmtf

---

From: [email-masked]
Date: Fri, 28 Jun 2013 10:57:25 +0200

Hi all,

Few days ago Julian talked about TCM-TF's security and now I've read  
in the link included by Dan, saying that the gain obtained when  
multiplexing Ipsec-encrypted packets is 20-to-1. We have been looking  
for more information about this issue and thinking about a way to  
reduce the needed  bandwidth in IPsec flows.

The main idea is to find a way to change the authentication of the  
individual packets and merge all of them in a unique authentication.  
Thus, instead of using 20 IPsec tunnels, we would have a single tunnel  
including 20 flows. Is this something similar than how Cisco gets the  
improvement?

José Luis

Dan Wing <[email-masked]> ha escrito:

>> 1) TCM-TF intends to update RFC4170, which optimizes RTP VoIP   
>> traffic. So if RFC4170 was interesting, why not updating it?
>>
>> - Aggregation network of *network operators*: We are saving   
>> bandwidth by optimizing and putting together traffic flows. Is this  
>>  interesting for a network operator? What about overprovisioning?   
>> The idea is that there are places and moments in which a number of   
>> flows based on small packets are in the same place and at the same   
>> moment. Then, TCM-TF can be applied in order to provide   
>> flexibility. We are not optimizing the overall Internet traffic, we  
>>  are optimizing specific flows with very tight delay requirements,   
>> which network operators have to take care of in a special way.
>> - *End to end* optimization: Nowadays, many appliances are used to   
>> connect remote offices of the same company (creating a VPN). So if   
>> a tunnel exists, why not optimizing this traffic when possible? We   
>> would save bandwidth in the access network, where it can be scarce.
>>
> "Cisco adds IP multiplexing to mobile satellite package", April   
> 2012,   
> http://www.networkworld.com/news/2012/040912-cisco-ip-multiplexing-258082.html
>
>
>
>>
>>
> Some networks, today, use cRTP (RFC2508) on their access links.    
> This gives bandwidth savings on the access link, but consumes   
> considerable CPU horsepower on the aggregation router (to perform   
> cRTP), but provides no bandwidth savings across the network core.    
> If, instead, the bandwidth could be saved on the access link, across  
>  the core, and on the far-end access link -- all without the CPU   
> impact on the aggregation router -- it is a considerable win.
>
> -d
>
>
>
>>
>>
>> Jose
>>
>> 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.
>>