[6lowapp] On selecting protocols: latency before flexibility or the other way around?

[Arjun Roychowdhury <[e-mail]>]

Hi,my apologies if this discussion has been initiated before (I did not see
it though, in the archives)

I've been reading the past threads of discussions with a lot of interest and
I notice that most discussions put latency and payload size ahead of
discussing the features that could drive these devices. I just wonder if
this group should consider switching the priorities around - first agree on
what are the best features this network can benefit from and then address
which protocols & formats meet these needs and what can be done to optimize
them for the characteristics of the underlying network. It's an approach I
think that 6lowpan itself took - isn't it? IPV6 was chosen due to its
several advantages and then, RFC 4944 decided how to best optimize and/or
compress it. In my mind, features and flexibility of the
carrier protocols are more important than whether it supports millisecond
response times "as it stands today" - just my past experience that when we
make design choices based on size first, we make compromises on the best
solution and ignore "adaptations" that could solve the latency and timing
issues (if that were not the case, we would never have binary XML, JSON,
SIGCOMPed SIP and even 6lowPAN which adapted popular protocols to various
network conditions).

So the short of it, I'd love to see a discussion on:
a) What are the features we believe the current and next generation devices
will bring in, if given a chance ?
b) What are the control mechanisms that users would like if devices were
able to offer more functionality?

regds
arjun


-- 
Arjun Roychowdhury
Hughes Systique Corp.