Re: Comparison of compression algorithms

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

Received on Wednesday, 2 September 2020 15:38:09 UTC