Subject: [tcmtf] Improvements in the TCM-TF charter draft v8

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Nov 2013 12:13:44 +0100

Hi all.

We have the idea of asking for a BoF in London in March 2014. For this aim,
we should discuss a new version of the charter draft. I send it in the next
e-mail.

This e-mail summarizes the improvements. I have put different numbers, in
order to discuss them separately in the list.

1- In order to be consistent with the drafts, the charter should talk about
"TCM-ingress and egress optimizers" instead of "TCM multiplexers and
demultiplexers".

2- A new scenario has been included "a wireless Internet connection shared
by a number of people in a place with low Internet penetration", taking into
account that some people from Africa were interested on TCM for improving
real-time applications in this kind of places.

3- Scenario: "a community network, in which a number of people in the same
geographical place share their connections in a cooperative way". It has
some similarities with the previous one.
https://en.wikipedia.org/wiki/Community_network. 

4- Scenario: "a satellite connection used for providing connectivity in a
non-connected area during a short period of time (e.g. journalists covering
the arrival of a mountain stage of a cycling competition)."

5- Scenario: " -	an air-to-ground connection providing Internet
connectivity to the passengers of an aircraft, multiplexing a number of
simultaneous VoIP flows. The same can be applied between a cruise ship and a
satellite." http://www.gogoair.com/gogo/cms/work.do

6- According to the feedback received in the BoF in Berlin, the references
to TCP have been removed.

7- A reference to the potential problem of the MTU and packet loss has been
added in number 8: "The eventual impact of multiplexing on protocol dynamics
(e.g. the lost of a multiplexed packet, MTU-related issues) will also have
to be addressed.."

Any other suggestions, according to what we discussed in the BoF?
http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf

Best regards,

Jose Saldana

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 20 Nov 2013 14:04:20 +0000

Hi,

why is ROHC not a solution?

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Nov 2013 16:24:56 +0100

Hi, Lars.

ROHC in fact is the most important part of the solution, since it is the
algorithm that reduces the size of the headers dramatically. Since the
header and the payload are in the same order of magnitude, the saving is
significant. ROHC can be enough if you are considering a single hop.

But if you want to use it in more than a single hop, ROHC has to be
tunneled, and you lose the savings achieved by compression. So the idea is
that a number of packets (multiplexed) share the tunnel overhead.

Best regards,

Jose

-----Mensaje original-----
De: tcmtf [mailto:[email-masked]] En nombre de Eggert, Lars
Enviado el: miércoles, 20 de noviembre de 2013 15:04
Para: [email-masked]
CC: [email-masked]; Martin Stiemerling; [email-masked]
Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8

Hi,

Lars

On 2013-11-20, at 6:13, Jose Saldana <[email-masked]> wrote:

> Hi all.
> 
> We have the idea of asking for a BoF in London in March 2014. For this 
> aim, we should discuss a new version of the charter draft. I send it 
> in the next e-mail.
> 
> This e-mail summarizes the improvements. I have put different numbers, 
> in order to discuss them separately in the list.
> 
> 1- In order to be consistent with the drafts, the charter should talk 
> about "TCM-ingress and egress optimizers" instead of "TCM multiplexers 
> and demultiplexers".
> 
> 2- A new scenario has been included "a wireless Internet connection 
> shared by a number of people in a place with low Internet 
> penetration", taking into account that some people from Africa were 
> interested on TCM for improving real-time applications in this kind of
places.
> 
> 3- Scenario: "a community network, in which a number of people in the 
> same geographical place share their connections in a cooperative way". 
> It has some similarities with the previous one.
> 4- Scenario: "a satellite connection used for providing connectivity 
> in a non-connected area during a short period of time (e.g. 
> journalists covering the arrival of a mountain stage of a cycling
competition)."
> connectivity to the passengers of an aircraft, multiplexing a number 
> of simultaneous VoIP flows. The same can be applied between a cruise 
> ship and a satellite." http://www.gogoair.com/gogo/cms/work.do
> 
> 6- According to the feedback received in the BoF in Berlin, the 
> references to TCP have been removed.
> 
> 7- A reference to the potential problem of the MTU and packet loss has 
> been added in number 8: "The eventual impact of multiplexing on 
> protocol dynamics (e.g. the lost of a multiplexed packet, MTU-related 
> issues) will also have to be addressed.."
> 
>

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Wed, 20 Nov 2013 15:44:54 +0000

+1.

Hi,
   When you have more than a single hop in the long same path you need a other way to get that type of saving without using ROHC in each segment.

Regards,
    Manuel.

-----Mensaje original-----
De: tcmtf [mailto:[email-masked]] En nombre de Jose Saldana
Enviado el: miércoles, 20 de noviembre de 2013 16:25
Para: 'Eggert, Lars'
CC: [email-masked]; 'Martin Stiemerling'; [email-masked]
Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8

Hi, Lars.

ROHC in fact is the most important part of the solution, since it is the algorithm that reduces the size of the headers dramatically. Since the header and the payload are in the same order of magnitude, the saving is significant. ROHC can be enough if you are considering a single hop.

But if you want to use it in more than a single hop, ROHC has to be tunneled, and you lose the savings achieved by compression. So the idea is that a number of packets (multiplexed) share the tunnel overhead.

Best regards,

Jose

-----Mensaje original-----
De: tcmtf [mailto:[email-masked]] En nombre de Eggert, Lars Enviado el: miércoles, 20 de noviembre de 2013 15:04
Para: [email-masked]
CC: [email-masked]; Martin Stiemerling; [email-masked]
Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8

Hi,

Lars

places.
competition)."
> http://www.ietf.org/proceedings/87/minutes/minutes-87-tcmtf

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

________________________________

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: "Eggert, Lars" <[email-masked]>
Date: Wed, 20 Nov 2013 16:19:45 +0000

Hi,

> that a number of packets (multiplexed) share the tunnel overhead.

several of the scenarios you describe for TCM-TF seem to be fully addressed by ROHC, i.e., do not seem to have multiple L3 hops that require creation of a tunnel.

It would be good to explicitly limit yourself to describing scenarios that do have that requirement.

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Nov 2013 18:15:46 +0100

Lars,

You are totally right. If there is a single hop, ROHC will be enough. 

The next scenarios may have a single hop:

- a satellite connection used for providing connectivity in a non-connected
area during a short period of time (e.g. journalists covering the arrival of
a mountain stage of a cycling competition).
- an air-to-ground connection providing Internet connectivity to the
passengers of an aircraft, multiplexing a number of simultaneous VoIP flows.

Regarding these other two scenarios, perhaps TCM-TF would only be
interesting when there is a community network in which packets have to
traverse a (frequently high) number of hops:

- a wireless Internet connection shared by a number of people in a place
with low Internet penetration
- a community network, in which a number of people in the same geographical
place share their connections in a cooperative way

For example, in this scenario a community network with a high number of hops
is considered: http://www.guifi.net/en/guifi_zones. There is also a paper
about the topology of community networks: "On the topology characterization
of Guifi.net" http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103

Thanks for your feedback!

Jose

-----Mensaje original-----
De: tcmtf [mailto:[email-masked]] En nombre de Eggert, Lars
Enviado el: miércoles, 20 de noviembre de 2013 17:20
Para: [email-masked]
CC: [email-masked]; Martin Stiemerling; [email-masked]
Asunto: Re: [tcmtf] Improvements in the TCM-TF charter draft v8

Hi,

On 2013-11-20, at 10:24, Jose Saldana <[email-masked]> wrote:
> tunneled, and you lose the savings achieved by compression. So the 
> idea is that a number of packets (multiplexed) share the tunnel overhead.

several of the scenarios you describe for TCM-TF seem to be fully addressed
by ROHC, i.e., do not seem to have multiple L3 hops that require creation of
a tunnel.

It would be good to explicitly limit yourself to describing scenarios that
do have that requirement.

Lars

---

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 20 Nov 2013 17:19:35 +0000

Hi,

> a mountain stage of a cycling competition).

where does this scenario have multiple L3 hops involved? The bottleneck link is the satellite hop.

> passengers of an aircraft, multiplexing a number of simultaneous VoIP flows.

Ditto, the bottleneck here is air-to-ground.

Lars

---

From: "Jose Saldana" <[email-masked]>
Date: Wed, 20 Nov 2013 18:32:18 +0100

Hi, Lars.

In my previous e-mail I was saying that those two scenarios (cycling
competition and air-to-ground) involved a single hop, so they should be
removed.

So we agree.

Thanks,

Jose

> De: Eggert, Lars [mailto:[email-masked]]
> Enviado el: miércoles, 20 de noviembre de 2013 18:20
> Para: [email-masked]
> > - a satellite connection used for providing connectivity in a
> > non-connected area during a short period of time (e.g. journalists
> > covering the arrival of a mountain stage of a cycling competition).
> 
> where does this scenario have multiple L3 hops involved? The bottleneck
link
> is the satellite hop.
> > - a wireless Internet connection shared by a number of people in a
> > place with low Internet penetration
> > - a community network, in which a number of people in the same
> > geographical place share their connections in a cooperative way
> >
> > For example, in this scenario a community network with a high number
> > of hops is considered: http://www.guifi.net/en/guifi_zones. There is
> > also a paper about the topology of community networks: "On the
> > topology characterization of Guifi.net"
> > http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=6379103
> >
> > several of the scenarios you describe for TCM-TF seem to be fully
> > addressed by ROHC, i.e., do not seem to have multiple L3 hops that
> > require creation of a tunnel.
> >

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Wed, 20 Nov 2013 15:32:39 -0500

If there is a discussion about charter I would like to see how this is different from any other 'transport accelerators' especially if the use cases now include VoIP, wireless and satellite links not just real time gaming or video streaming.

/mjm

Marie-José Montpetit
[email-masked]

> On Nov 20, 2013, at 11:19, "Eggert, Lars" <[email-masked]> wrote:
> 
> Hi,
>

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 21 Nov 2013 11:56:21 +0000

Hi Marie,

I think transport accelerators are more focused in optimizing single data flows (compression and maybe tunneling). The main difference here would be the multiplexing of several data flows of different users. Please, if I am misunderstand you, provide more information about any other transport accelerator.

Un saludo,
Fernando

Fernando Pascual Blanco
Network Automation and Dynamization | Telefonica Global Resources
C/ Don Ramón de la Cruz 82-82, 28006, Madrid, España
[email-masked]<mailto:[email-masked]> |F +34 91 312 8779  |  M +34 682 005 168

On 20/11/2013, at 21:32, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

/mjm

Marie-José Montpetit
[email-masked]<mailto:[email-masked]>

Hi,

Lars

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Thu, 21 Nov 2013 07:00:59 -0500

Look at QUIC amongst others.

Marie-José Montpetit
[email-masked]
[email-masked]

> On Nov 21, 2013, at 6:56, FERNANDO PASCUAL BLANCO <[email-masked]> wrote:
> 
> Hi Marie,
> 
> [email-masked] |F +34 91 312 8779  |  M +34 682 005 168
> 
>> On 20/11/2013, at 21:32, Marie-Jose Montpetit <[email-masked]> wrote:
>>

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Thu, 21 Nov 2013 15:39:17 +0000

Hi Marie,

After reading a while QUIC (https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit), I understand that it tunnel and multiplex several transport flows between a client and a server. It works over UDP and could be very useful when web browsing because there is a lot of TCP flows interacting (one per web object).
Nevertheless, TCM-TF intends to be transparent for the end points and can tunnel, multiplex and compress several flows from different users between two any points within the network: for example, between a game server placed in Germany and one point aggregating hundreds of players in Spain (a transport router or whatever).

Regards,
Fernando

Fernando Pascual Blanco

On 21/11/2013, at 13:00, Marie-Jose Montpetit <[email-masked]<mailto:[email-masked]>> wrote:

Marie-José Montpetit
[email-masked]<mailto:[email-masked]>
[email-masked]<mailto:[email-masked]>

On Nov 21, 2013, at 6:56, FERNANDO PASCUAL BLANCO <[email-masked]<mailto:[email-masked]>> wrote:

Hi Marie,

Un saludo,
Fernando

Fernando Pascual Blanco

/mjm

Marie-José Montpetit

On Nov 20, 2013, at 11:19, "Eggert, Lars" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On 2013-11-20, at 10:24, Jose Saldana <[email-masked]<mailto:[email-masked]>> wrote:
But if you want to use it in more than a single hop, ROHC has to be
tunneled, and you lose the savings achieved by compression. So the idea is
that a number of packets (multiplexed) share the tunnel overhead.

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