https://github.com/w3c/automotive/issues/336
assigned to Ted to complete what he already proposed some time ago and move VISS to PR
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
https://www.w3.org/XML/EXI/docs/json/exi-for-json.html
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
Ulf: we need to start working on agenda for upcoming TPAC
Ted: I'll start a wiki