All, Shortened Names: - I agree with Dan that we should not have aliases for parameter names. We should just decide on the short names - I would only shorten the names that are highly repeated, such as those in the Spectrum message, as Don suggested.
Compression: - I agree we should just rely on standard HTTP compression and, as Dan suggests: - “Recommended” for WS Databases, and optional for WS Clients. On a separate note, HTTPS is required. Are the radio vendors concerned about supporting that? -vince On Mon, Dec 9, 2013 at 8:02 AM, Harasty, Daniel J <[email protected]>wrote: > All, > > > > While I don’t necessarily agree with all of Don’s reasons, I’m not opposed > to us adopting some means to shorten the messages. > > > > Here’s my proposal: > > · If we want to consider “more concise” / “less wordy” tag names, > fine by me. We can shorten things like “powerDbmPerBw” to “power” or > simply “db”. > > o Sure, that makes the protocol a wee-bit less “human readable”. > However, if it makes it more “machine friendly” ala Don’s view, that is > probably acceptable. After all: the human should be reading the spec… > > o Note that shortening the longer tags that appear repeatedly (such as > in the “spectra” list) will give us the most “bang for the buck” in this > effort. > > · Let’s not mess around with **optional** “short form” tags. > > o Either a tag is short or long; let’s not add complexity by creating > something like aliases. > > · If we want to consider some actual compression, let’s not > invent something new here. I haven’t heard of any standardize way to > compress JSON… but since HTTP is the presumptive transport, why not just > rely on “standard” HTTP compression? > > o See: http://en.wikipedia.org/wiki/HTTP_compression > > o I would make support the spec stating this is “recommended” for WS > Databases, and optional for WS Clients. > > > > Will actual compression help? Turns out we’ve experimented a bit with > this even before Don’s email, so here’s one data point: we found many of > the AVAIL_SPECTRUM_RESP messages to be in the range of 17k characters. A > simple call to a zlib compression algorithm on that string typically > shortened it to about 1k characters. (This was specifically using the HTTP > compression techniques, but I expect the compression rate to be similar.) > > > > Here’s my concern: > > · If memory management is an issue in the radios, then don’t we > actually make things WORSE by compression? After all, if a 17k message is > compressed down to 1k… then the TRANSPORT of the message is sped up… but > the message now has to exist in the client’s memory – at least briefly – in > BOTH the compressed and decompressed form. > > > > Just a quick viewpoint to consider: In my opinion, at the heart of the > matter, the desire of some participants is to make a VERY GENERAL message > structure to AVAIL_SPECTRUM_RESP that will suit multiple use cases in > multiple countries. This is at odds with brevity, and therefore may be at > odds with certain radio-implementation constraints. > > · For example, a given device which is only going to operate in > the US gains nothing from this verbosity of our current generic structure. > To wit, for US purposes, the whole SpectrumSchedule could be condensed to > something a lot like this: > > avail_chans: {5: 4000, 12: 4000, 16: 100, 17: 100, 18: 100, 31: 40, 41: 40} > > representing that channels 5 and 12 are available at 4000mW, channels 16, > 17, and 18 are available at 100mW, and channels 31 and 41 are available at > 40mW. This alone represents a savings of the majority of the 17k > characters. (Admittedly, the “time” aspect of the schedule would still > need to be addressed.) > > > > Dan Harasty > > > > > > *From:* paws [mailto:[email protected]] *On Behalf Of * > [email protected] > *Sent:* Friday, December 06, 2013 5:26 PM > *To:* [email protected]; [email protected] > *Subject:* Re: [paws] Proposal to optionally support shortened message > format > > > > You are asking for a json compression mechanism, for understandable > reasons. I was actually surprised this issue did not come up earlier. > > We first need to have a discussion to see if there’s consensus for the > need of a compression mechanism, and if yes, then see how do we get one in > place. > > I did not find any json compression related work in ietf, but a quick > search found few available algorithms. Do we have on this list JSON experts > who could give some advice? > > Gabor > > > > > > *From:* paws [mailto:[email protected] <[email protected]>] *On > Behalf Of *ext Don Joslyn > *Sent:* Friday, December 06, 2013 11:15 AM > *To:* [email protected] > *Subject:* [paws] Proposal to optionally support shortened message format > > > > All, > > > > While working closely with a number of white space radio vendors that wish > to support the PAWS protocol, some have expressed concerns with the size of > paws messages, especially the size of an AVAIL_SPECTRUM_RESP message that > supports Ofcom requirements and includes every channel. One issue raised is > that when these messages are very large (in this case >14k bytes), > requiring several MTU’s of packet data, their radio device does not have > enough available RAM (or resources) to support the required packet > buffering, especially when their device is being used as a master with > several attached slaves. A second issue raised is the amount of traffic > generated by these control messages, reducing the bandwidth available for > user data traffic. The worst case is a master device supporting several > slave devices where every device is required to periodically request a new > channel list (and the periodic interval requirement seems to be getting > smaller). Both issues are serious concerns for these radio vendors, and > unless we do something to resolve it, they may not be able to support the > paws protocol. A further concern for radio developers is energy expended > per transmitted bit. This is a major issue for battery powered devices. > > > > I would like to propose that we support an optional shortened message > format, by creating a two-character alias for each defined parameter’s text > name, without making any changes to message structure. We would be > shortening the parameter text names, not the parameter data values. When a > device sends a message to the database with shortened parameter names, the > presence of shortened parameter names could serve as a trigger for the > database to reply to the device using shortened parameter names in the > reply message. > > > > This would be fairly easy to express in the current document by adding a > paragraph to explain the support for shortened messages and adding a > two-character alias in parenthesis next to each defined parameter name. I > have attached an example to this email as a markup to page 40 of the > version 7 draft. > > In the example, I have defined two-character aliases for several parameter > names, and included a sample “spectrum” section that uses shortened > parameter names. > > > > The sample uses the following aliases: > > > > “spectrum” = “sp” > > “resolutionBwHz” = “bw” > > “profiles” = “pf” > > “freqHz” = “hz” > > “powerDbmPerBw” = “pw” > > > > We could define the shortened parameter names and make support of > shortened messages optional to allow database owners to decide if they want > to support shortened messages or not. > > > > If there is support for this proposal, I would volunteer to update the > version 7 draft to help move it forward. > > > > Thank you, > > Don > > _______________________________________________ > paws mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/paws > > -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
