Subject: Re: [tcmtf] More satellite scenarios

From: "Jose Saldana" <[email-masked]>
Date: Fri, 28 Sep 2012 12:19:39 +0200

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#axzz27l0sEqu3
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-coverage-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:[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_savin
> > gs
> >
> >  >>>>>>.pd
> >
> >  >>>>>>f
> >
> >  >>>>>>
> >
> >  >>>>>>
> >
> >
> >
> >>>>>>http://diec.unizar.es/~jsaldana/personal/tcmtf_figures/m2m_scena
> > 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Fri, 28 Sep 2012 13:06:55 +0100

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