Subject: [tcmtf] Discussing M2M scenario and savings

From: "Jose Saldana" <[email-masked]>
Date: Tue, 4 Sep 2012 09:40:40 +0200

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

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Tue, 04 Sep 2012 10:27:22 +0000

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]] On Behalf Of Jose Saldana
Sent: martes, 04 de septiembre de 2012 9:41
To: [email-masked]
Cc: [email-masked]; [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:

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

---

From: "Jose Saldana" <[email-masked]>
Date: Thu, 13 Sep 2012 17:20:23 +0200

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]] On Behalf Of
Jose Saldana
Sent: martes, 04 de septiembre de 2012 9:41
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [tcmtf] Discussing M2M scenario and savings

Hi again,

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

Only a comment to avoid misunderstanding: the last sentence of the previous
message “… sharing the same origin and destination” is not correct. What you
need is a common path shared by a number of flows. Multiplexing can be
applied in the whole path or even in a single hop (e.g. the critical
bottleneck).

Regards,

Jose
----------------------

De: [email-masked] [mailto:[email-masked]] En nombre de Jose
Saldana
Enviado el: jueves, 13 de septiembre de 2012 17:20
Para: 'FERNANDO PASCUAL BLANCO'; [email-masked]
Asunto: Re: [tcmtf] Discussing M2M scenario and savings

- 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.

Do you agree? 

Jose

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

Hi all,

Regards,
 
Fernando

Hi again,

 

Thanks,
 
Jose

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Mon, 17 Sep 2012 09:40:24 +0000

Hi Jose,

        That was my point: a network carrier has a satellite link or long
distance wire and decides to implant TCMTF in that hop (tipically a
bottleneck). IP sources/destinations may not be the same (multiple flows
are sharing the same link) and QoS requirements may not be the same (same
reason). Nevertheless, although header compression is not optimal
(different sources/destinations), any save in that link would be
appreciated.

Saludos,

Fernando Pascual Blanco
Telefónica Global Resources
Network Automation and Dynamization
TECHNOLOGY PEOPLE GROUP
F +34913128779
M +34682005168
[email-masked]

On 17/09/12 09:35, "Jose Saldana" <[email-masked]> wrote:

>message ³Š sharing the same origin and destination² is not correct. What
>you
>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
>use
>_______________________________________________
>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: Gorry Fairhurst <[email-masked]>
Date: Tue, 18 Sep 2012 19:46:37 +0100

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:
> -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
> 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:
>
> 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
>
> ------------------------------------------------------------------------
>
>

---

From: FERNANDO PASCUAL BLANCO <[email-masked]>
Date: Wed, 19 Sep 2012 08:24:01 +0000

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