Subject: Re: [tcmtf] More satellite scenarios

From: "Jose Saldana" <[email-masked]>
Date: Mon, 1 Oct 2012 12:15:05 +0200

Gorry,

The question here is that perhaps the scenario of the sensor network in
http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pdf was
too simplistic, and TCMTF made no sense for it, since the use of IP would
not be necessary, as you remarked. There are more interesting compressing
options for that scenario. Am I correct?

Thanks for your feedback,

Jose

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]] En nombre de
> Gorry Fairhurst
> Enviado el: viernes, 28 de septiembre de 2012 14:07
> Para: [email-masked]
> Asunto: Re: [tcmtf] More satellite scenarios
> 
> I did not dispute the use of VoIP and other "small packet" services over
> satellite (I work on this subject). What I wanted to understand was why
> ROHC or RFC 3545 (e.g. for VoIP) was not applicable.
> 
> Gorry
> 
> On 28/09/2012 11:19, Jose Saldana wrote:
> > We have to continue the discussion about satellite scenarios with
> > sensor
> > networks: if possible, I would like to hear the opinion of people from
> > DLR about this.
> >
> >
> > However, I have found more satellite-related scenarios in which a
> > number of small-packet flows can be present:
> >
> > - A cruise: lots of people (3800 people in Queen Mary 2) connected
> > through a satellite link
> >
> >
> http://www.cruisemates.com/articles/onboard/connected.cfm#axzz27l0sEq
> u
> > 3
> > http://en.wikipedia.org/wiki/RMS_Queen_Mary_2
> > http://www.esa.int/esaTE/SEMMAWNFGLE_index_0.html
> >
> >
> > - A plane: similar to the ship, but less people and no satellite, but
> > ground antennas communicating with a special antenna on the plane
> > (VoIP is prohibited by now):
> > http://en.wikipedia.org/wiki/Gogo_Inflight_Internet
> >
> >
> > - Satellite access in low-populated regions (e.g. Alaska): Perhaps a
> > number of people, or a village, may share a  connection through an
> antenna:
> > http://www.skycasters.com/satellite-internet-coverage/skycasters-cover
> > age-Al
> > aska.html
> >
> >
> > What do you think?
> >
> > Best regards,
> >
> > Jose
> >
> >> -----Mensaje original-----
> >> De: [email-masked] [mailto:[email-masked]] En nombre
> >> de Gorry Fairhurst Enviado el: viernes, 21 de septiembre de 2012
> >> 10:29
> >> Para: [email-masked]
> >> CC: [email-masked]; 'FERNANDO PASCUAL BLANCO'
> >> Asunto: Re: [tcmtf] Discussing M2M scenario and savings - continuing
> >> the thread
> >>
> >> 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.
> >>>
> >>> I am talking about this figure:
> >>>
> >>> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.
> >>> pd
> >>> f
> >>>
> >>> 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
> >>>
> >>> Telefónica Global Resources
> >>>
> >>> Network Automation and Dynamization
> >>>
> >>> 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:
> >>>
> >>>   >
> >>>
> >>>   >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] <mailto:[email-masked]>
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >>
> >>>
> >>>   >> On 19/09/12 10:56, "[email-masked]
> >>> <mailto:[email-masked]>" <[email-masked]
> >>> <mailto:[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] <mailto:[email-masked]>
> >>>
> >>>   >>>>
> >>>
> >>>   >>>>
> >>>
> >>>   >>>>
> >>>
> >>>   >>>>
> >>>
> >>>   >>>> On 18/09/12 20:46, "Gorry Fairhurst" <[email-masked]
> >>> <mailto:[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:tcmtf-
> [email-masked]]
> >>> <mailto:[mailto:[email-masked]]> *En
> >>>
> >>>   >>>>>> nombre de *FERNANDO PASCUAL BLANCO *Enviado el:*
> martes,
> >> 04 de
> >>>
> >>>   >>>>>> septiembre de 2012 12:27
> >>>
> >>>   >>>>>> *Para:* [email-masked] <mailto:[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:tcmtf-
> >> [email-masked]>
> >>>
> >>>   >>>>>> [mailto:[email-masked]]
> >>> <mailto:[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]>
> >>> <mailto:[email-masked]>
> >>>
> >>>   >>>>>> *Cc:* [email-masked] <mailto:[email-masked]>
> >>> <mailto:[email-masked]>;
> >>>
> >>>   >>>>>> [email-masked] <mailto:[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_savi
> >>>>>>>> n
> >>> gs
> >>>
> >>>   >>>>>>.pd
> >>>
> >>>   >>>>>>f
> >>>
> >>>   >>>>>>
> >>>
> >>>   >>>>>>
> >>>
> >>>
> >>>
> >>>>>>>>
> http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scen
> >>>>>>>> a
> >>> ri
> >>>
> >>>   >>>>>>o.p
> >>>
> >>>   >>>>>>df
> >>>
> >>>   >>>>>>
> >>>
> >>>   >>>>>> 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] <mailto:[email-masked]>
> >>>
> >>>   >>>>>> https://www.ietf.org/mailman/listinfo/tcmtf
> >>>
> >>>   >>>>>>
> >>>
> >>>   >>>>>
> >>>
> >>>   >>>>>_______________________________________________
> >>>
> >>>   >>>>>tcmtf mailing list
> >>>
> >>>   >>>>>[email-masked] <mailto:[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
> >>>
> >>>   >>
> >>>
> >>>   >
> >>>
> >>>   >
> >>>
> >>>   >
> >>>
> >>>   >_______________________________________________
> >>>
> >>>   >tcmtf mailing list
> >>>
> >>>   >[email-masked] <mailto:[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
> >>>
> >>> _______________________________________________
> >>>
> >>> tcmtf mailing list
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>>
> >>> https://www.ietf.org/mailman/listinfo/tcmtf
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> tcmtf mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/tcmtf
> >>>
> >>
> >> _______________________________________________
> >> tcmtf mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/tcmtf
> >
> > _______________________________________________
> > tcmtf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tcmtf
> >
> 
> _______________________________________________
> tcmtf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcmtf

---

From: [email-masked]
Date: Mon, 1 Oct 2012 11:29:53 +0100

That is what I think - the proposed tunnel method does not seem to have
advantage when used over a single link.

Gorry

---

From: "Jose Saldana" <[email-masked]>
Date: Mon, 1 Oct 2012 15:00:53 +0200

Tomaso,

I think you are correct. TCMTF is interesting when the satellite link is not
the only hop.

The question is: are there real sensor networks in which IP is necessary?

Some possible examples (please tell me if some of them exist in the real
world):

- Cameras or more complicated sensors generating IP packets
- Different groups of sensors which share the same satellite link to deliver
their data to the server, so you need IP in order to distinguish between
them
- Sensors sending data to different destination servers

Thanks,

Jose

> De: [email-masked] [mailto:[email-masked]]
> Enviado el: lunes, 01 de octubre de 2012 14:41
> Para: [email-masked]; [email-masked]
> CC: [email-masked]
> Asunto: RE: [tcmtf] More satellite scenarios
> 
> If I understand it right we have a proposal for tunneling, multiplexing,
> (header-)compressing general IP flows, which clearly brings gains for
short
> packets.
> As Gorry said, multiplexing is basically already done below IP in sat
networks,
> and header compression can always be added on top.
> So the only need for doing this above IP and tunnel it (i.e. this
proposal) is
> when the IP links extend beyond the sat link on one or both sides.
> Is this correct?
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: 01 October 2012 12:30
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [tcmtf] More satellite scenarios
> 
> > http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scenario.pd
> > f
> > was
> > too simplistic, and TCMTF made no sense for it, since the use of IP
> > would not be necessary, as you remarked. There are more interesting
> > compressing options for that scenario. Am I correct?
> >
> >> de Gorry Fairhurst Enviado el: viernes, 28 de septiembre de 2012
> >> 14:07
> >> Para: [email-masked]
> >> I did not dispute the use of VoIP and other "small packet" services
> >> over satellite (I work on this subject). What I wanted to understand
> >> was why ROHC or RFC 3545 (e.g. for VoIP) was not applicable.
> >>
> >> Gorry
> >>
> >> > networks: if possible, I would like to hear the opinion of people
> >> > from DLR about this.
> >> >
> >> >
> >> > - A plane: similar to the ship, but less people and no satellite,
> >> > but ground antennas communicating with a special antenna on the
> >> > plane (VoIP is prohibited by now):
> >> > - Satellite access in low-populated regions (e.g. Alaska): Perhaps
> >> > a number of people, or a village, may share a  connection through
> >> > an
> >> antenna:
> >> >> nombre de Gorry Fairhurst Enviado el: viernes, 21 de septiembre de
> >> >> 2012
> >> >> 10:29
> >> >> Para: [email-masked]
> >> >> Asunto: Re: [tcmtf] Discussing M2M scenario and savings -
> >> >> continuing the thread
> >> >>
> >> >> 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
> >> >> 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
> >> >>> 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.
> >> >>>
> >> >>> Asunto: Re: [tcmtf] Discussing M2M scenario and savings -
> >> >>> continuing the thread
> >> >>>
> >> >>> Hi Gorry,
> >> >>>
> >> >>>   >>>I know there are applications for tunnel compression - but
> >> >>> I'm not
> >> >>>
> >> >>>   >>>>>A satellite "link" may provide HC, at least some of the
> >> >>> ones I have
> >> >>>
> >> >>>   >>>>>> -If you are a costumer, and you have to pay for a
> >> >>> satellite link
> >> >>>
> >> >>>   >>>>>>America and other one in  Europe, you may be interested
> >> >>> on placing
> >> >>>
> >> >>>   >>>>>>may  try to  use TCMTF in the best place: a high number
> >> >>> of flows,
> >> >>>
> >> >>>   >>>>>> Yes, M2M sensor networks are a very good example in
> >> >>> order to save
> >> >>>
> >> >>>   >>>>>> bandwidth in long distance/big latency/low bandwidth
> >> >>> links, links
> >> >>>
> >> >>>   >>>>>> *Cc:* [email-masked]
> >> >>> <mailto:[email-masked]> <mailto:[email-masked]>;
> >> >>>
> >> >>>   >>>>>> 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
> >> >>>
> >> >>> only send

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Mon, 01 Oct 2012 14:03:56 +0000

Yes, I agree with both and the scenario is raised too simple, and the main advantages are obtained when there are several networks after the satellite link and the mux-demux is made end to end.
I am going to describe it with an example. Imagine a group of M2M sensors with a mux close to gateway (as in the figure), for example sensors in natural parks around Europe to prevent fires. Each group of these sensors send their data through a satellite link to a next hop, and from there the data are sent to centralized data center in Brussels (for example) to process, to analyze and to take decisions. The demux should be located just across that data center.

Manuel.

-----Mensaje original-----
De: [email-masked] [mailto:[email-masked]] En nombre de [email-masked]
Enviado el: lunes, 01 de octubre de 2012 12:30
Para: [email-masked]
CC: [email-masked]; [email-masked]
Asunto: Re: [tcmtf] More satellite scenarios

That is what I think - the proposed tunnel method does not seem to have advantage when used over a single link.

Gorry

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: Tue, 2 Oct 2012 08:55:22 -0700

> Of MANUEL NUÑEZ SANZ
> Sent: Monday, October 01, 2012 7:04 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Yes, I agree with both and the scenario is raised too simple, and the
> main advantages are obtained when there are several networks after the
> satellite link and the mux-demux is made end to end.

Also, some implementation experience:  Cisco has long had cRTP and 
(TCP) VJ header compression in our various devices.  It is CPU intensive.  
Van Jacobson, when he worked at Cisco, did a deep dive into the 
implementation to improve it, but found no fundamental flaws with
its implementation.

Thus, even if mux/compression seems like a good idea on the
satellite link itself, it consumes CPU horsepower exactly where
it is difficult to handle -- at an aggregation point with lots
of data flowing.  Better to do it once (rather than at every "slow"
link), and do it closer to the producer/consumer so it isn't done
at a large aggregation point.

-d

> I am going to describe it with an example. Imagine a group of M2M
> sensors with a mux close to gateway (as in the figure), for example
> sensors in natural parks around Europe to prevent fires. Each group of
> these sensors send their data through a satellite link to a next hop,
> and from there the data are sent to centralized data center in Brussels
> (for example) to process, to analyze and to take decisions. The demux
> should be located just across that data center.
> 
> Manuel.
> 
> 
> [email-masked]
> >> > http://www.skycasters.com/satellite-internet-coverage/skycasters-
> co
> >> > ver
> >> > age-Al
> >> > aska.html
> >> >
> >> >
> >> > What do you think?
> >> >
> >> > Best regards,
> >> >
> >> > Jose
> >> >
> >> >>> benefit in a multi-router hop path, being the satellite-link
> part
> >> >>> of
> > this
> >> path.
> >> >>>
> >> >>> Regards,
> >> >>>
> >> >>> Fernando Pascual Blanco
> >> >>>
> >> >>>   >For a point-to-point link carrying traffic destined to a
> ingle
> >> >>> L2
> >> >>>
> >> >>>   >>>>>>per  second  or  money. If you have e.g. two offices,
> one
> >> >>> in
> >> >>>
> >> >>>>>>>>> ----------------------------------------------------------
> -
> >> >>>>>>>>> ---
> >> >>>>>>>>> --
> >> >>> --
> >> >>>
> >> >>>   >>>>>>---
> >> >>>
> >> >>>   >>>>>>--
> >> >>>
> >> >>>   >>>>>>-
> >> >>>
> >> >>>   >>>>>>
> >> >>>
> >> >>>   >>>>>>
> >> >>>
> >> >>>   >>>>>> send and receive email on the basis of the terms set
> out
> >> at:
> >> >>>
> consultar nuestra política de envío y recepción de correo electrónico
> en el enlace situado más abajo.

---

From: MANUEL NUÑEZ SANZ <[email-masked]>
Date: Tue, 02 Oct 2012 16:02:08 +0000

Ok, these experimental data reinforce the idea mux-demux  ​​end to end, and it is more useful when crossing areas narrowband and high delay such as satellite links.

Manuel.

-----Mensaje original-----
De: Dan Wing [mailto:[email-masked]]
Enviado el: martes, 02 de octubre de 2012 17:55
Para: MANUEL NUÑEZ SANZ; [email-masked]; [email-masked]
CC: [email-masked]
Asunto: RE: [tcmtf] More satellite scenarios

Also, some implementation experience:  Cisco has long had cRTP and
(TCP) VJ header compression in our various devices.  It is CPU intensive.
Van Jacobson, when he worked at Cisco, did a deep dive into the implementation to improve it, but found no fundamental flaws with its implementation.

Thus, even if mux/compression seems like a good idea on the satellite link itself, it consumes CPU horsepower exactly where it is difficult to handle -- at an aggregation point with lots of data flowing.  Better to do it once (rather than at every "slow"
link), and do it closer to the producer/consumer so it isn't done at a large aggregation point.

-d

> and from there the data are sent to centralized data center in
> Brussels (for example) to process, to analyze and to take decisions.
> The demux should be located just across that data center.
>
> Manuel.
>
>
> de [email-masked] Enviado el: lunes, 01 de octubre de 2012 12:30
> Para: [email-masked]
> That is what I think - the proposed tunnel method does not seem to
> have advantage when used over a single link.
>
> Gorry
>
> > Gorry,
> >
> >> nombre de Gorry Fairhurst Enviado el: viernes, 28 de septiembre de
> >> 2012
> >> 14:07
> >> Para: [email-masked]
> >> over satellite (I work on this subject). What I wanted to
> >> understand was why ROHC or RFC 3545 (e.g. for VoIP) was not applicable.
> >>
> >> Gorry
> >>
> >> > - A cruise: lots of people (3800 people in Queen Mary 2)
> >> > connected through a satellite link
> >> >
> >> >
> >>
> >> > - Satellite access in low-populated regions (e.g. Alaska):
> >> > Perhaps a number of people, or a village, may share a  connection
> >> > through an
> >> antenna:
> >> >> 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
> >> >> as drawn, since this seems more like *link* HC, and it would
> >> >> seem foolish
> >> > to
> >> >> obvious where bandwidth is high. Also, it would seem desirable
> >> >> to use encapsulation and HC mechanisms on the satellite air
> interface
> >> >> anyway, RFC
> >> >>> 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.
> >> >>>
> >> >>>   >> it compress packet headers (IP-TCP/UDP). If, in addition
> >> >>> to that, we
> >> >>>
> >> >>>   >>>>>> We already discussed some points about the M2M
> >> >>> scenario at the
> >> >>>
> >> >>>   >>>>>> Perhaps we could comment them, in order to discuss
> >> >>> this scenario,
> >> >>>