I am not sure I get Brian's point, but....
The kind of TVWS devices I am dealing with fall into a couple groups.
We have mains powered, resource rich devices that have an internet
connection, all the memory needed to implement a complete IP protocol
stack including PAWS, and a high data rate connection to the internet.
An 802.11 access point is an example of this sort of device.
There are battery or mains powered, transitory devices that have the
resource to implement a complete IP stack, assume a reasonable high data
rate connection to the internet, have the battery capacity to operate
for a couple days between recharging. An 802.11 STA in a portable
device (phone, tablet, PC) might be an example of this kind of device.
Another example is a M2M device with moderate (1Mbps) interface through
a gateway.
A resource constrained device may have no IP stack, or a stripped down
IP stack (UDP, 6loWPAN, ...). Some may have to run for many years on
battery. Likely no direct internet connection, or squeezes through a
gateway on a very low data rate wireless link. It may have only an
wireless interface. Raw bit rate is low (100kbps or less) and
effective throughput much lower. Such devices may be "sleepy" meaning
they turn off all but a few gates most of the time, only communicate
when there is something to say. A low cost remote sensor is an example
of this sort of device.
PAWS is targeted at the first category, and IMO will work for the
second category. Not ideal for the last category. I think the
fundamental assumptions driving protocol design are so different that it
would be a mistake at this stage to try and make PAWS fit the really
slim device.
Hope that helps.
Ben
On 12/10/2013 5:53 AM, Rosen, Brian wrote:
<personal opinion>
I don't have an objection to doing that, but it won't do anything
substantial to the problem.
We have had discussions like this on many protocols over the years.
Our experience is this kind of thing has little effect on
implementations other than complicating debugging.
Using a formal compression scheme on the entire message often helps
substantially reduce message size, also substantially complicates
debugging, and, in general, we don't think it actually helps
implementations.
You really think that reducing message sizes from, say 14KB to, say
10KB, which any decent compression system should be able to do, would
actually make any difference to a device implemented this year? If
those Ks were Ms, it might be worth thinking about, but Ks? Please.
Shorter names probably only changes messages sizes by 10% or so,
clearly insufficient to do anything other than confuse humans.
Brian
From: Ray Bellis <[email protected]
<mailto:[email protected]>>
Date: Tuesday, December 10, 2013 at 8:34 AM
To: Don Joslyn <[email protected]
<mailto:[email protected]>>
Cc: "[email protected] <mailto:[email protected]>" <[email protected]
<mailto:[email protected]>>
Subject: Re: [paws] Proposal to optionally support shortened message
format
On 10 Dec 2013, at 13:03, Don Joslyn <[email protected]
<mailto:[email protected]>> wrote:
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?
That's my understanding of what has been proposed, and I think it's a
good idea.
Ray
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
_______________________________________________
paws mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/paws
