Automotive Working Group Teleconference

25 Aug 2020



Daniel, Ulf, Peter, Glenn, Ted, Ashish, Gunnar



assigned to Ted to complete what he already proposed some time ago and move VISS to PR

Issue 336

Payload compression presentation


Ulf: we have been approached by some companies interested in payload compression as JSON is a bit heavy
... I started to look into it and enlisted Sanjeev
... created a compression algorithm to try to balance cpu and compression rate
... it is JSON aware and utilizes lookup tables
... implemented already in my fork of Gen2 implementation
... 3-5x compression but should be able to get 4.5-7x
... implemented only on websockets but could be extended to http
... I feel it is more important in web sockets
... design pattern to invoke this could be extended to use more well known algorithms instead like gzip
... I don't think it should be part of standard but could be in best practices or separate note
... we do not need the full 32 bytes of uuid since we do not have that many nodes
... 4-6 bytes are sufficient
... payload message is divided up into pieces
... there is a predefined list of keywords
... data values limited to 128 ascii characters
... using subset of uuid as mentioned to be more efficient. also able to encode timestamps in similar manner

[slide with sample json data and gen2 request]

[example goes from 317 bytes to 69]

Peter: interesting, we are doing similar for offboarding data but using gzip
... have you done a comparison?

Ulf: I haven't, believe cpu cost will be higher with gzip
... unsure the ratio
... believe the advantage is with larger volume of data


Ted: what you have is knowledgeable of and specific for the data we're using
...we might want to consider being consistent with http and consider gzip or other known algos, see what is used commonly with web sockets
...I was going to suggest EXI for JSON but see it first bloats JSON as XML and they are more in the high volume off-boarding data eg military, aerospace and intelligence whereas we are looking at smaller on-board transmission

Ulf: also deflate in http
... agree we should look more at existing algorithms and as mentioned can support alternate algorithms

Gunnar: my benchmark on json was 2.5x
... you know data set you're sending, shortened uuid, keywords make sense
... since you are not sending json anyway, shouldn't you consider a different format like protobuf or avro
... another thought is server and client could agree on what translation table looks like and be able to reduce bytes further

Peter: I wanted to find out if people had time to do their reviews yet

Ted: partially done with mine, will finish and send to github. please get them in sooner so we can discuss those points before next week when we want to process the pull request

Ulf: for late corrections, we can continue conversation and refine per convention
... please be mindful of the hassle lots of tweaks are to the editors

Status access control pr review

TPAC time doodle


Ulf: we need to start working on agenda for upcoming TPAC

Ted: I'll start a wiki

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/08/31 14:29:18 $