Dan, Vince, When you say that you don't want to have aliases and just want to decide on short names, does that mean that the current long names would be changed to short names and the long names would not be supported?
Don From: Vincent Chen [mailto:[email protected]] Sent: Tuesday, December 10, 2013 1:57 AM To: Harasty, Daniel J Cc: [email protected]; Don Joslyn; [email protected] Subject: Re: [paws] Proposal to optionally support shortened message format 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]<mailto:[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]<mailto:[email protected]>] On Behalf Of [email protected]<mailto:[email protected]> Sent: Friday, December 06, 2013 5:26 PM To: [email protected]<mailto:[email protected]>; [email protected]<mailto:[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]] On Behalf Of ext Don Joslyn Sent: Friday, December 06, 2013 11:15 AM To: [email protected]<mailto:[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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/paws -- -vince
_______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
