Subject: [tcmtf] Discussing M2M scenario and savings - continuing the thread

From: [email-masked]
Date: Wed, 19 Sep 2012 11:37:24 +0100

For a point-to-point link carrying traffic destined to a ingle L2 address,
I don't see how this helps above the gains of ROHC or some other HC on the
link, when possibly combining this with link layer transmission options
e.g. methods like PDU-CONCAT in RFC 5163.

If you're working over a multi-router network hop, the considerations may
be different.

Gorry

> Hi Gorry,
>
>         I don´t know a lot about link layer HC, but I imagine that it
> compress
> packet headers (IP-TCP/UDP). If, in addition to that, we group several
> small packets into a bigger one (using PPP-Mux and RoHC), don´t you
> think
> more resources could be saved?
>
> Regards,
>
> Fernando Pascual Blanco
> Telefónica Global Resources
> Network Automation and Dynamization
> TECHNOLOGY PEOPLE GROUP
> F +34913128779
> M +34682005168
> [email-masked]
>
>
>
>
> On 19/09/12 10:56, "[email-masked]" <[email-masked]> wrote:
>
>>I know there are applications for tunnel compression - but I'm not sure
>> I
>>understand how this can gain further than for link-layer HC?
>>
>>Gorry
>>
>>> Hi Gorry,
>>>
>>>         In addition of HC (header compression), the multiplexing layer
>>> will save
>>> even more resources. In that case and assuming that all the traffic
>>> through the link have the same QoS requirements (for example a sensor
>>> network), the idea would be to group all the flows through the link
>>> (the
>>> bottleneck).
>>>
>>> Regards,
>>>
>>> Fernando Pascual Blanco
>>> Telefónica Global Resources
>>> Network Automation and Dynamization
>>> TECHNOLOGY PEOPLE GROUP
>>> F +34913128779
>>> M +34682005168
>>> [email-masked]
>>>
>>>
>>>
>>>
>>> On 18/09/12 20:46, "Gorry Fairhurst" <[email-masked]> wrote:
>>>
>>>>A satellite "link" may provide HC, at least some of the ones I have
>>>> seen
>>>>do. In this case, the flows can easily be grouped by mac address?
>>>>
>>>>Gorry
>>>>
>>>>On 13/09/2012 16:20, Jose Saldana wrote:
>>>>> Hi, Fernando, sorry for the delay (one week, I¹m afraid).
>>>>>
>>>>> I don¹t know who is the one interested on using TCMTF:
>>>>>
>>>>> -If you are a costumer, and you have to pay for a satellite link or
>>>>> a
>>>>> long distance wire, perhaps you are the one interested on using
>>>>> end-to-end TCMTF, since you will save bandwidth or packets per
>>>>> second
>>>>> or
>>>>> money. If you have e.g. two offices, one in America and other one in
>>>>> Europe, you may be interested on placing a device for multiplexing a
>>>>> number of VoIP calls between them. You have one advantage: the flows
>>>>> have the same origin and destination, so header compression is
>>>>>effective.
>>>>>
>>>>> -If you are the operator of the satellite, you have another problem:
>>>>> you
>>>>> may have to check every flow, and try to group them. Perhaps it may
>>>>> be
>>>>> easy, but if you want to save headers, you need flows with the same
>>>>> origin and destination.
>>>>>
>>>>> I think that there are different scenarios, and each ³actor² may
>>>>> try
>>>>>to
>>>>> use TCMTF in the best place: a high number of flows, with small
>>>>> packets,
>>>>> and sharing the same origin and destination.
>>>>>
>>>>> Do you agree?
>>>>>
>>>>> Jose
>>>>>
>>>>> *De:[email-masked] [mailto:[email-masked]] *En
>>>>> nombre
>>>>> de *FERNANDO PASCUAL BLANCO
>>>>> *Enviado el:* martes, 04 de septiembre de 2012 12:27
>>>>> *Para:* [email-masked]
>>>>> *Asunto:* Re: [tcmtf] Discussing M2M scenario and savings
>>>>>
>>>>> Hi all,
>>>>>
>>>>> Yes, M2M sensor networks are a very good example in order to save
>>>>> bandwidth in long distance/big latency/low bandwidth links, links
>>>>> were
>>>>> the cost per bit is high. Do you think network carriers operating
>>>>> this
>>>>> kind of links (satellite links or long distance wires) would be
>>>>> interested in apply TCMTF?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Fernando
>>>>>
>>>>> *From:[email-masked] <mailto:[email-masked]>
>>>>> [mailto:[email-masked]]
>>>>> <mailto:[mailto:[email-masked]]>
>>>>> *On Behalf Of *Jose Saldana
>>>>> *Sent:* martes, 04 de septiembre de 2012 9:41
>>>>> *To:* [email-masked] <mailto:[email-masked]>
>>>>> *Cc:* [email-masked] <mailto:[email-masked]>;
>>>>> [email-masked] <mailto:[email-masked]>
>>>>> *Subject:* [tcmtf] Discussing M2M scenario and savings
>>>>>
>>>>> Hi again,
>>>>>
>>>>> We already discussed some points about the M2M scenario at the
>>>>> beginning
>>>>> of August. We are currently studying this, and we have built some
>>>>> figures, in collaboration with people from DLR (Tomaso and Matteo).
>>>>>You
>>>>> can find the figures here:
>>>>>
>>>>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings.pdf
>>>>>
>>>>>
>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf
>>>>>
>>>>> Perhaps we could comment them, in order to discuss this scenario,
>>>>> and
>>>>> we
>>>>> may find new ones in which TCMTF can be useful.
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> tcmtf mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/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
>>>
>>
>>
>
>
> ________________________________
>
> 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: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 19 Sep 2012 11:02:03 +0000

Hi Gorry,

        Absolutely. The tunneling layer would increase that benefit in a
multi-router hop path, being the satellite-link part of this path.

Regards,

Fernando Pascual Blanco

On 19/09/12 12:37, "[email-masked]" <[email-masked]> wrote:

>>         I donÂ´t know a lot about link layer HC, but I imagine that it
>> compress
>> small packets into a bigger one (using PPP-Mux and RoHC), donÂ´t you
>> think
>> TelefÃ³nica Global Resources
>>>> TelefÃ³nica Global Resources
>>>>>> Hi, Fernando, sorry for the delay (one week, IÂ¹m afraid).
>>>>>>
>>>>>> I donÂ¹t know who is the one interested on using TCMTF:
>>>>>>
>>>>>> I think that there are different scenarios, and each Â³actorÂ² may
>>>>>> try
>>>>>>to
>>>>>> nuestra polÃ­tica de envÃ­o y recepciÃ³n de correo electrÃ³nico en
>>>>>> el
>>>>>> enlace
>>>>>> situado mÃ¡s abajo.
>>>> nuestra polÃ­tica de envÃ­o y recepciÃ³n de correo electrÃ³nico en el
>>>> enlace
>>>> situado mÃ¡s abajo.
>> nuestra polÃ­tica de envÃ­o y recepciÃ³n de correo electrÃ³nico en el
>> enlace situado mÃ¡s abajo.

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: "Jose Saldana" <[email-masked]>
Date: Thu, 20 Sep 2012 18:20:35 +0200

So, do you think the figure should be modified? Perhaps it is currently confusing, since it seems that RFC 5163 is the best solution. Perhaps a network should be included between the demux and the data center? Or between the antenna and the demux? Will this be a real case? I don't know if in the right side it is possible to find other networks.

I am talking about this figure:

Thanks,

Jose

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: miércoles, 19 de septiembre de 2012 13:02
Para: [email-masked]; [email-masked]
Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread

Hi Gorry,

        Absolutely. The tunneling layer would increase that benefit in a multi-router hop path, being the satellite-link part of this path.

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

 <mailto:[email-masked]> [email-masked]

 

On 19/09/12 12:37, " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]> wrote:

>For a point-to-point link carrying traffic destined to a ingle L2 

>address, I don't see how this helps above the gains of ROHC or some 

>other HC on the link, when possibly combining this with link layer 

>transmission options e.g. methods like PDU-CONCAT in RFC 5163.

>If you're working over a multi-router network hop, the considerations 

>may be different.

>>         I donÂ´t know a lot about link layer HC, but I imagine that 

>> it compress packet headers (IP-TCP/UDP). If, in addition to that, we 

>> group several small packets into a bigger one (using PPP-Mux and 

>> RoHC), donÂ´t you think more resources could be saved?

>>  <mailto:[email-masked]> [email-masked]

>> On 19/09/12 10:56, " <mailto:[email-masked]> [email-masked]" < <mailto:[email-masked]> [email-masked]> wrote:

>>>I know there are applications for tunnel compression - but I'm not 

>>>sure  I understand how this can gain further than for link-layer HC?

>>>>         In addition of HC (header compression), the multiplexing 

>>>> layer will save even more resources. In that case and assuming that 

>>>> all the traffic through the link have the same QoS requirements 

>>>> (for example a sensor network), the idea would be to group all the 

>>>> flows through the link (the bottleneck).

>>>> Network Automation and Dynamization TECHNOLOGY PEOPLE GROUP F 

>>>> +34913128779 M +34682005168  <mailto:[email-masked]> [email-masked]

>>>> On 18/09/12 20:46, "Gorry Fairhurst" < <mailto:[email-masked]> [email-masked]> wrote:

>>>>>seen do. In this case, the flows can easily be grouped by mac 

>>>>>address?

>>>>>> -If you are a costumer, and you have to pay for a satellite link 

>>>>>>or  a  long distance wire, perhaps you are the one interested on 

>>>>>>using  end-to-end TCMTF, since you will save bandwidth or packets 

>>>>>>per  second  or  money. If you have e.g. two offices, one in 

>>>>>>America and other one in  Europe, you may be interested on placing 

>>>>>>a device for multiplexing a  number of VoIP calls between them. 

>>>>>>You have one advantage: the flows  have the same origin and 

>>>>>>destination, so header compression is effective.

>>>>>> may have to check every flow, and try to group them. Perhaps it 

>>>>>> may be easy, but if you want to save headers, you need flows with 

>>>>>> the same origin and destination.

>>>>>> I think that there are different scenarios, and each Â³actorÂ² 

>>>>>>may  try to  use TCMTF in the best place: a high number of flows, 

>>>>>>with small  packets,  and sharing the same origin and destination.

>>>>>> *De:[email-masked]  <mailto:[mailto:[email-masked]]> [mailto:[email-masked]] *En 

>>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:* martes, 04 de 

>>>>>> septiembre de 2012 12:27

>>>>>> *Para:*  <mailto:[email-masked]> [email-masked]

>>>>>> were the cost per bit is high. Do you think network carriers 

>>>>>> operating this kind of links (satellite links or long distance 

>>>>>> wires) would be interested in apply TCMTF?

>>>>>> *From:[email-masked] < <mailto:[email-masked]> mailto:[email-masked]> 

>>>>>>  <mailto:[mailto:[email-masked]]> [mailto:[email-masked]] 

>>>>>> < <mailto:[mailto:[email-masked]]> mailto:[mailto:[email-masked]]>

>>>>>> *To:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>>>>>> *Cc:*  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>; 

>>>>>>  <mailto:[email-masked]> [email-masked] < <mailto:[email-masked]> mailto:[email-masked]>

>>>>>>beginning  of August. We are currently studying this, and we have 

>>>>>>built some  figures, in collaboration with people from DLR (Tomaso 

>>>>>>and Matteo).

>>>>>> <http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings

>>>>>>.pd

>>>>>>f

>>>>>> <http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenari> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenari

>>>>>>o.p

>>>>>>df

>>>>>> and we may find new ones in which TCMTF can be useful.

>>>>>>------------------------------------------------------------------

>>>>>>---

>>>>>>--

>>>>>> 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> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

>>>>>>  <mailto:[email-masked]> [email-masked]

>>>>>>  <https://www.ietf.org/mailman/listinfo/tcmtf> https://www.ietf.org/mailman/listinfo/tcmtf

>>>>> <mailto:[email-masked]> [email-masked]

>>>>> <https://www.ietf.org/mailman/listinfo/tcmtf> https://www.ietf.org/mailman/listinfo/tcmtf

>>>> 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> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

>> consultar nuestra polÃ­tica de envÃ­o y recepciÃ³n de correo 

>> electrÃ³nico en el enlace situado mÃ¡s abajo.

>> and receive email on the basis of the terms set out at:

>>  <http://www.tid.es/ES/PAGINAS/disclaimer.aspx> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

> <mailto:[email-masked]> [email-masked]

> <https://www.ietf.org/mailman/listinfo/tcmtf> https://www.ietf.org/mailman/listinfo/tcmtf

 <http://www.tid.es/ES/PAGINAS/disclaimer.aspx> http://www.tid.es/ES/PAGINAS/disclaimer.aspx

tcmtf mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/tcmtf> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Fri, 21 Sep 2012 07:47:01 +0000

Hi Jose,

I think there will be several layer 3 hops between the demux and the data center and not in the other side.

Regards,

Fernando Pascual Blanco

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Organization: Universidad de Zaragoza
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: jueves 20 de septiembre de 2012 18:20
To: Fernando Pascual Blanco <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread

Thanks,

Jose

-----Mensaje original-----
De: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] En nombre de FERNANDO PASCUAL BLANCO
Enviado el: miércoles, 19 de septiembre de 2012 13:02
Para: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing the thread

Hi Gorry,

Regards,

Fernando Pascual Blanco

TECHNOLOGY PEOPLE GROUP

F +34913128779

M +34682005168

[email-masked]<mailto:[email-masked]>

On 19/09/12 12:37, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

>> [email-masked]<mailto:[email-masked]>

>> On 19/09/12 10:56, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:

>>>> +34913128779 M +34682005168 [email-masked]<mailto:[email-masked]>

>>>> On 18/09/12 20:46, "Gorry Fairhurst" <[email-masked]<mailto:[email-masked]>> wrote:

>>>>>> *De:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> *En

>>>>>> *Para:* [email-masked]<mailto:[email-masked]>

>>>>>> *From:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>>>>> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

>>>>>> *To:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>>>>> *Cc:* [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>;

>>>>>> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

>>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_savings

>>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenari

>>>>>> [email-masked]<mailto:[email-masked]>

>>>>>[email-masked]<mailto:[email-masked]>

>[email-masked]<mailto:[email-masked]>

tcmtf mailing list

[email-masked]<mailto:[email-masked]>

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 21 Sep 2012 09:29:04 +0100

I think *IF* the satellite link is a DVB 2nd generation RF link, e.g. 
DVB-S2 for satellite ( a common waveform), then GSE + RFC 5163 is a 
reasonable proposal, on which one may benefit if one layers a HC scheme, 
such as ROHC, or 6LoWPAN. The profile for the  ROHC schemes have not 
been specified for this type of link - but the relevant RFCs exist for 
the compression itself. RFC 3135 and RFC 3449 also describe TCP/IP 
techniques to help improve efficiency on such links.

As I said, I do not see the *benefit* for the mux and demux in the 
scenario as drawn, since this seems more like *link* HC, and it would 
seem foolish to form aggregate traffic over a single link layer in the 
way that tunnel compression implements this.

If the drawing extended the network on one or both sides of the 
satellite link, there could be a reason for using tunnel HC, although I 
am not sure whether this is commercially important, since unlike an 
access network, the connectivity to the hub (usually known as the 
satellite gateway) on the left of the figure is not usually a low speed 
access link and the merits of HC is less obvious where bandwidth is 
high. Also, it would seem desirable to use encapsulation and HC 
mechanisms on the satellite air interface anyway, RFC 3135 part 3 (from 
the source), possibly combined with RFC 3449 mechanisms.

All I am saying is you have to be sure to describe the scenario 
carefully and explain why HC applies in this case and what alternatives 
exist.

Gorry

On 20/09/2012 17:20, Jose Saldana wrote:
> So, do you think the figure should be modified? Perhaps it is currently
> confusing, since it seems that RFC 5163 is the best solution. Perhaps a
> network should be included between the demux and the data center? Or
> between the antenna and the demux? Will this be a real case? I don't
> know if in the right side it is possible to find other networks.
>
>          Absolutely. The tunneling layer would increase that benefit in
> a multi-router hop path, being the satellite-link part of this path.
>
> Regards,
>
> Fernando Pascual Blanco
>
> [email-masked] <mailto:[email-masked]>
>
> On 19/09/12 12:37, "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>  >
>
>  >> [email-masked] <mailto:[email-masked]>
>
>  >>
>
>  >>
>
>  >>
>
>  >>
>
>  >> On 19/09/12 10:56, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>  >>
>
>  >>>> +34913128779 M +34682005168 [email-masked] <mailto:[email-masked]>
>
>  >>>>
>
>  >>>>
>
>  >>>>
>
>  >>>>
>
>  >>>>>> *De:[email-masked] [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]> *En
>
>  >>>>>> *Para:* [email-masked] <mailto:[email-masked]>
>
>  >>>>>> *To:* [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>
>  >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]>;
>
> <mailto:[email-masked]>
>
>  >>>>>> [email-masked] <mailto:[email-masked]>
>
>  >>>>>[email-masked] <mailto:[email-masked]>
>
>  >[email-masked] <mailto:[email-masked]>
>
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
>
> [email-masked] <mailto:[email-masked]>
>