W3C home > Mailing lists > Public > public-automotive@w3.org > September 2020

Re: Comparison of compression algorithms

From: Ulf Bjorkengren <ulfbjorkengren@geotab.com>
Date: Thu, 3 Sep 2020 10:41:11 +0200
Message-ID: <CAHfMbK82Evw5dYDxs+C9TjBhnBk6oKEUE6Yd3Ou96Lkmn1NZnA@mail.gmail.com>
To: Ted Guild <ted@w3.org>
Cc: Gunnar Andersson <gandersson@genivi.org>, public-automotive <public-automotive@w3.org>
>>  Say you're managing several million vehicles. Do you want to poll them
frequently wondering if they are on/running and online (within cell
reception)?

A use case like this may be better solved with a push paradigm.
But there are also use cases where a pull paradigm is to prefer.
What I say is that we should try to make Gen2 support both paradigms as
well as possible.
To do this for pull use cases,compression support for Gen2 payloads is one
relevant feature.

BR
Ulf

On Wed, Sep 2, 2020 at 5:38 PM Ted Guild <ted@w3.org> wrote:

> It may well not be an absolute truth but those are rather strong
> influencers. MagnusF affirmed that is why they are why they push to
> cloud instead of pull from.
>
> Say you're managing several million vehicles. Do you want to poll them
> frequently wondering if they are on/running and online (within cell
> reception)? Those will often go unanswered. Even if pull (Gen2
> requests) is permitted it likely would only be from OEM cloud servers
> and not independent garage, fleet managers' servers. Those connections
> can timeout from tunnels, parking garages etc and would want to be able
> to buffer regardless of push/pull.
>
> Discussed in brief during GENIVI CCS call. I agree with Ulf we are open
> to Gen2 being used however OEM or other implementers prefer.
>
> Off-boarding in CCS scope diagram:
>
>
> https://at.projects.genivi.org/wiki/pages/viewpage.action?pageId=44859735&preview=/40402952/47711462/communication-architecture-draft-CCS.pdf
>
> As mentioned, there are perhaps some things such as supporting binary
> or other format output to subscriptions in Gen2 that would benefit both
> push and pull provided we keep both in mind.
>
> On Tue, 2020-09-01 at 21:35 +0200, Ulf Bjorkengren wrote:
> > >> For a variety of reasons (security, connectivity, car being off),
> > data being off-boarded from vehicle to the cloud will be pushed, not
> > pulled.
> > I don't see this being an absolute truth. I think the concerns
> > mentioned can be mitigated, thus enabling the pull scenario.
> > I guess it is the OEMs that ultimately makes this call, so I hope to
> > hear their view on it.
> > BR
> > Ulf
> >
> >
> > On Tue, Sep 1, 2020, 21:10 Ted Guild <ted@w3.org> wrote:
> > > On Tue, 2020-09-01 at 11:28 -0400, Ted Guild wrote:
> > > > We can/should also explore alternate formats Gunnar suggested
> > > >
> > > > https://en.wikipedia.org/wiki/Apache_Avro
> > > > https://en.wikipedia.org/wiki/Protocol_Buffers
> > > >
> > > > As these messages being transmitted are fairly small to begin
> > > with
> > > > and
> > > > in-vehicle use case will have extremely low latency, I also want
> > > to
> > > > try
> > > > to understand how/where this would be more useful as
> > > > encoding/compressing and decoding will cost time and depending on
> > > > method non-negligible cpu. If the client app is just sampling to
> > > > offboard and won't unpack (decode), then we probably should look
> > > at
> > > > Extended Vehicle and other solutions being used for off-boarding
> > > in
> > > > addition to formats. What problem[s] are we trying to solve here?
> > >
> > > We confirmed on the call today the primary use case is for off
> > > boarding
> > > data.
> > >
> > > For a variety of reasons (security, connectivity, car being off),
> > > data
> > > being off-boarded from vehicle to the cloud will be pushed, not
> > > pulled.
> > >
> > > Gen2 server instance can reside either in-vehicle or on a server in
> > > the
> > > cloud.
> > >
> > > For in-vehicle client apps that will be residing on the vehicle or
> > > nearby (local network) trusted devices, compression is not needed.
> > > Cloud servers will not be permitted to connect to Gen2 (ports not
> > > open)
> > > on a vehicle to make pull requests. Gen2 supports clients making
> > > pulls,
> > > HTTP GET and subscribe on Web Socket, it cannot initiate a push to
> > > server in the cloud.
> > >
> > > Gen2 supporting alternate, including binary, formats besides JSON
> > > for
> > > more efficient local storage until it can send buffered data off
> > > the
> > > vehicle would help with 'every byte counts' when sending data off
> > > the
> > > vehicle.
> > >
> > > VSS in protobuf format can make a ton of sense, perhaps with some
> > > further optimization along lines of what Ulf and Sanjeev have been
> > > working on.
> > >
> > > Gen2 server residing in the cloud, exposing data already off-
> > > boarded
> > > can respond to pull requests from client apps running elsewhere in
> > > the
> > > cloud. Compression makes sense there.
> > >
> > > If someone has a different architecture in mind where vehicle<-
> > > >cloud
> > > connections differ fundamentally or we can translate a pull to push
> > > by
> > > redirecting and caching/buffering data, I would like to hear it.
> > >
> --
> Ted Guild <ted@w3.org>
> W3C Automotive Lead
> https://www.w3.org/auto
>
>

-- 
Ulf Bjorkengren
*Geotab*
Senior Connectivity Strategist | Ph. D.
Mobile +45 53562142
Visit www.geotab.com
Received on Thursday, 3 September 2020 08:39:58 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 3 September 2020 08:39:58 UTC