Re: [Imap-protocol] Best way to support HTTP PUT based 'push' notifications from IMAP?

On 09/04/2013 03:43 PM, Jan Kundrát wrote:
> On Tuesday, 3 September 2013 12:53:00 CEST, Andrew Sutherland wrote:
>> On devices that either have difficulty maintaining persistent TCP 
>> connections or have power concerns about doing so, maintaining an 
>> IMAP connection for IDLE/NOTIFY purposes is undesirable and it would 
>> be great if the IMAP server could generate a notification via other 
>> means.
>
> I have heard this a couple of times, but there was never a pointer to 
> an article quantifying these claims. I understand that something 
> different than TCP (e.g. an incoming SMS) could have a very different 
> impact on power consumption simply because it utilizes a different 
> part of the radio, but this proposal is about replacing one TCP 
> connection with another one. So, why do you expect that this change 
> will reduce power consumption, and do you have any measurements or 
> other data?

So there are 2 separate issues here.

1) Maintaining the connection.

1a) Wi-fi connections.  Firefox OS shuts down the wi-fi when we turn off 
the screen if we are on battery power unless some application has a 
wi-fi wake-lock.  It's my understanding that wi-fi is somewhat power 
hungry, but either way, wi-fi off is going to take less power than wi-fi 
on, no matter what.  So all connections established via wi-fi will die.  
We could re-establish them via cellular data, of course.

1b) Cellular data connections.  I think this is a theory-versus-practice 
thing, at least in the markets that Firefox OS devices have been 
targeting.  In theory, it should be possible for the device to roam 
around without losing its TCP connection if the tower infrastructure 
maintains the IP/NAT mapping and routes the packets to the right tower.  
What I am told and my own limited experience bears out in the markets 
that I have been to is that the connections end up dropping/hanging.  As 
you say, any TCP-based push notification would be subject to these same 
problems.


2) Power levels.  A presentation I saw quite some time ago made by 
Telefonica Digital, but whose slides I am unable to find characterized 
the cellular radio power usage as similar to a CPU and its varying sleep 
levels.  An idle TCP connection would actually let us get down to the 
second lowest power level.  Not the best, but not the end of the world.  
As Timo says, using/maintaining one TCP connection is better than 
maintaining N TCP connections.  Also important issue is that keeping a 
TCP connection alive means keeping the application that owns it alive 
too and that is not without its costs.  Our initial Firefox OS devices 
have 256 MiB of memory, with about half of that available for 
applications, so there's not a lot of spare capacity for one app to be 
hanging around, and definitely not multiple apps.

In terms of replacing TCP with TCP, my understanding is that we actually 
have 3 implementation approaches on the table for communication with the 
push notification server.  The most preferred implementation is 
SMS-based or something similar using the control channel of the cellular 
network which is both reliable and allows for the cellular radio to go 
to its lowest power level.  I believe this requires carrier 
participation and so is not available for all devices.  The next best 
solution is UDP-based; the device still needs to maintain an IP address 
but there is less overhead or risk of the connection hanging in a weird 
way.  I believe heartbeats/pings are used for the UDP approach to ensure 
that we haven't lost touch with the server.  The last approach is based 
on polling.  The push implementation wakes up and then talks to the 
server to see if there's a new event.  That might be what the UDP 
solution degrades to when the heartbeats aren't getting through.

And of course having a single native C++ thread waking up to perform the 
polling is generally better for resource usage than having N 
uncoordinated HTML/JS-based apps either waking up or using alarms to go 
through their entire startup process to perform their own polling.  I 
believe we are looking at supporting some type of coordinated polling 
process for apps that do have to poll for resource usage reasons so we 
take maximum advantage of having the CPU/radio/wi-fi all cranked up.

Andrew
_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol