Subject: Re: [lemonade] I-D ACTION:draft-ietf-lemonade-reconnect-client-02.txt

From: Randall Gellens <[email-masked]>
Date: Thu, 22 Feb 2007 15:25:32 -0800

At 1:49 PM +0000 1/31/07, Alexey Melnikov wrote:

>  So basically the client can't update its copy of HIGHESTMODSEQ with 
> FETCH MODSEQ until after it sees the tagged response for the 
> command.
>
>>  Do we expect connections to drop during resync often enough to be 
>> worth handling it specially?
>
>  Maybe we don't need to extend CONDSTORE to handle this specially, 
> but I think it is our duty to properly document how clients can 
> cope.

I agree this needs to be very clear.
-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly-selected tag: ---------------
All programmers are playwrights and all computers are lousy actors.

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: "Ben Last" <[email-masked]>
Date: Fri, 23 Feb 2007 08:48:51 -0000

>From: Randall Gellens [mailto:[email-masked]] 

Randy: I think that was your quote - apologies if I have misattributed it.

In our testing of our mobile client, we use a range of mailbox sizes: some are test and some (the larger) are real-world mailboxes.  Like mine, which is embarrassingly large, and those of a group of test users who are evaluating the first release of the client.  We find that connection drop during synchronization is actually fairly common.  Naturally, the chances of losing the connection during sync increase with the size of the mailbox, especially since we find that the client often needs to do a state-comparison sync after first login, and actual cellular data rates can be very slow at times.  We await the availability of CONDSTORE with great anticipation...

Also: sometimes even a rare condition is worth special case treatment if the *consequences* of that condition are sufficiently expensive.  A full resync of an inbox with 1000+ email in counts as expensive :)

Just for interest, some stuff we've found through mobile phone client testing:

Connection drops occur somewhat more often when the connection is over WiFi.  We're typically finding that mobile phone connectivity over WiFi suffers because of coverage blackspots that are usually not noticed because they're in places where people don't take laptops, because blackspot effects are worse for a phone because transmission power is lower and because the human body is an effective shield when a phone is raised to the head or worn in a pocket!  Since WiFi is effectively free compared with cellular data, though, it's the preferred way to connect.

Aggressive battery-saving (and cost-saving) measures include dropping out of push mode during the night, or when roaming.  When re-establishing a connection after a pushless period it's often necessary to perform a state-comparison sync.

Yours meanderingly
Ben

Ben Last
R & D Manager
EMCC Software Ltd

---

From: Randall Gellens <[email-masked]>
Date: Fri, 23 Feb 2007 10:19:44 -0800

>  Randy: I think that was your quote - apologies if I have misattributed it.

It was actually Philip Guenther, I believe.

>  In our testing of our mobile client, we use a range of mailbox 
> sizes: some are test and some (the larger) are real-world 
> mailboxes.  Like mine, which is embarrassingly large, and those of 
> a group of test users who are evaluating the first release of the 
> client.  We find that connection drop during synchronization is 
> actually fairly common.  Naturally, the chances of losing the 
> connection during sync increase with the size of the mailbox, 
> especially since we find that the client often needs to do a 
> state-comparison sync after first login, and actual cellular data 
> rates can be very slow at times.  We await the availability of 
> CONDSTORE with great anticipation...

Thanks for sharing this data, I think it's helpful, and a point we 
need to keep in mind.

I'd be interested to know which cellular data technology is being 
used, and also what the resynchronization technique is.  And 
naturally, what happens when CONDSTORE and QRESYNCH are used.

>  Also: sometimes even a rare condition is worth special case 
> treatment if the *consequences* of that condition are sufficiently 
> expensive.  A full resync of an inbox with 1000+ email in counts as 
> expensive :)
>
>  Connection drops occur somewhat more often when the connection is 
> over WiFi.  We're typically finding that mobile phone connectivity 
> over WiFi suffers because of coverage blackspots that are usually 
> not noticed because they're in places where people don't take 
> laptops, because blackspot effects are worse for a phone because 
> transmission power is lower and because the human body is an 
> effective shield when a phone is raised to the head or worn in a 
> pocket!  Since WiFi is effectively free compared with cellular 
> data, though, it's the preferred way to connect.

Very interesting.  Thanks for sharing this experience as well.

>  Aggressive battery-saving (and cost-saving) measures include 
> dropping out of push mode during the night, or when roaming.  When 
> re-establishing a connection after a pushless period it's often 
> necessary to perform a state-comparison sync.

Good point.

-------------- Randomly-selected tag: ---------------
Programming Department:  Mistakes made while you wait.

---

From: "Ben Last" <[email-masked]>
Date: Mon, 26 Feb 2007 08:00:30 -0000

>I wrote:
>>...We find 
>> that connection drop during synchronization is actually fairly common.  

>I'd be interested to know which cellular data technology is being used, and also what the
>resynchronization technique is.  And naturally, what happens when CONDSTORE and
>QRESYNCH are used.
GSM :)  And usually GRPS for the data, though 3G and WiFi also used where supported.  Dropouts happen with all the bearer technologies: WiFi that's quite acceptable for laptops in an office often shows many more blackspots when used with mobiles (due to the fact that mobiles are used in places that laptops aren't, and spend a lot of time in pockets next to human bodies).  The most common resynch is a state-comparison resynch, which in this case is a series of FETCH commands for UID and FLAGS (each fetch is for a range of message numbers).  We don't yet use CONDSTORE/QRESYNCH because the target server for the current release doesn't support them.

Regards
Ben

Ben Last 
R & D Manager
EMCC Software Ltd