Subject: RE: [lemonade] Profile WG last call

From: [email-masked]
Date: Tue, 25 Oct 2005 17:16:45 -0400

We have tried several things including keep alives and pings.
We have found that socket level keep alives don't work because the
carrier infrastructure doesn't reset the cells on keep alives in some
areas.
The best success we have had is by using app level pings (some random
data packet that is discarded) from the server to the client which keeps
the conneciton up.
On no 3G network we were able to set this at about 7 minutes.  On 3G
networks things were much worse and we had to lower it to 3-4 minutes.
In either case, the battery life was reduced, at a MINIMUM, by 50%.
Typically this was much worse when the user was traveling since the
power required by the radio increases with distance to the cell.

The ideal mechanism would be an out-of-band system like SMS which takes
no significant power loss from the terminal.  SIP doesn't seem to help
much since it is connection based as well.

Sugestions are very wellcome here.  At this point, battery life is at a
permium and people will turn off their email application to prevent
battery drain so they can continue to make/receive calls.

Corby Wilson

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Dave Cridland
> Sent: Tuesday, October 25, 2005 16:29 PM
> To: Arnt Gulbrandsen
> Cc: [email-masked]
> Subject: Re: [lemonade] Profile WG last call
> 
> On Tue Oct 25 20:21:27 2005, Arnt Gulbrandsen wrote:
> > Dave Cridland writes:
> >> This also makes me wonder whether a server-transmitted NOOP packet 
> >> might be possible, whether in IMAP or TCP, which might "hold" the 
> >> NAT connection state live. I don't know enough TCP to know whether 
> >> such a thing exists, nor do I know the internals of NATs et al to 
> >> know whether even if it does, it might help.
> > 
> > Such a thing exists in TCP, it's called keepalive. If you can turn 
> > it on, which isn't always, it defeats the NATs.
> > 
> > I think TLS has keepalives, too. That should be easy to enable from 
> > the application.
> 
> Both are easy to do from the application, TCP keep alives are a 
> socket option.
> 
> The trouble is, they require an acknowledgement from the other side, 
> so you're using up battery to send it.
> 
> What's really needed here is to send some packet from the IMAP server 
> which resets all the NAT timeouts, but doesn't require a 
> corresponding transmission from the handset.
> 
> Perhaps a duplicate ACK, for instance. (It's obviously a dirty hack, 
> but the NAT people started it, as my son would say).
> 
> Dave.
> -- 
>            You see things; and you say "Why?"
>    But I dream things that never were; and I say "Why not?"
>     - George Bernard Shaw
> 
> _______________________________________________
> lemonade mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/lemonade
> 

_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Oct 2005 14:49:45 -0700 (Pacific Daylight Time)

> power required by the radio increases with distance to the cell.

My experience with 1xRTT was that I had a connection going for nearly an 
hour (with a background ping to keep it alive) and I hadn't eaten up my 
battery.  That was about as long as I wanted to be online since I was 
paying voice minutes.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: "Stephane H. Maes" <[email-masked]>
Date: Tue, 25 Oct 2005 22:50:01 -0700

Corby,

Yes this also relates to the time out issue that we identified in draft-maes-lemonade-http-binding-03 and draft-smaes-lemonade-intermediary-challenges-03.  

Stability of the connection has user experience and battery life implications. 

Note that as we discussed in London, on HTTP the issue appeared much less problematic...

Stephane
_____
Stephane H. Maes, PhD,
Director of Architecture - OCS & Mobile, Oracle Corporation.
Ph: +1-203-300-7786 (mobile/SMS); Fax / Office UM: +1-650-607-6296.
e-mail: [email-masked]
IM: shmaes (AIM/Y!/skype) or [email-masked] (MSN Messenger)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 25, 2005 2:17 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [lemonade] Profile WG last call

Corby Wilson

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 26 Oct 2005 09:43:42 +0200

So if I understand this correctly, there aren't actually any arguments 
against IDLE as such. It's just that it's less use than on real 
networks, because a lot of networks discard TCP connections after some 
idleness, and keepalives cannot be used.

Two specific comments:

[email-masked] writes:
> data packet that is discarded) from the server to the client which 
> keeps the conneciton up.

This should be similar to TLS keepalives. (IIRC a TLS keepalive is just 
a packet with zero bytes plaintext and 16 bytes padding, all encrypted 
and sent to the peer.)

> battery drain so they can continue to make/receive calls.

Will carriers configure their networks to permit longer-lasting idleness 
so customers can use email effectively?

The issue isn't specific to IDLE. IDLE makes it show up clearly, but so 
does a complex SEARCH on a big mailbox. And of course IMAP permits a 
client to leave the connection idle without issuing IDLE. I think 
LEMONADE will eventually have to specify something like "carrier cannot 
discard TCP connections until at least x minutes have passed" or refer 
to the autlogout part of 3501.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Wed, 26 Oct 2005 11:33:12 +0100

On Wed Oct 26 08:43:42 2005, Arnt Gulbrandsen wrote:
> So if I understand this correctly, there aren't actually any 
> arguments against IDLE as such. It's just that it's less use than 
> on real networks, because a lot of networks discard TCP connections 
> after some idleness, and keepalives cannot be used.
> 
> 
Exactly.

>> The best success we have had is by using app level pings (some 
>> random data packet that is discarded) from the server to the 
>> client which keeps the conneciton up.
> 
> This should be similar to TLS keepalives. (IIRC a TLS keepalive is 
> just a packet with zero bytes plaintext and 16 bytes padding, all 
> encrypted and sent to the peer.)
> 
> 
Sure, but this requires at the very least an ACK at the TCP level.

>> Sugestions are very wellcome here. At this point, battery life is 
>> at a permium and people will turn off their email application to 
>> prevent battery drain so they can continue to make/receive calls.
> 
> Will carriers configure their networks to permit longer-lasting 
> idleness so customers can use email effectively?

The distinct impression I came away with from Stéphane's discussions 
at the Interim meeting was that the carriers won't fix, perhaps 
partly because they're unclear what the problem actually is.

Moreover, this problem affects more than just mobile networks, it 
affects most of the installed base of NAT, and some stateful 
inspection firewalls, too.

While I'd like to see people configuring such devices properly, 
ideally we need a solution that works now. For non-mobile 
environments, where transmission isn't so costly, TLS keepalives work 
fine. It's how to avoid transmissions on the part of the client 
that's the problem here.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 26 Oct 2005 15:31:25 +0100

> idleness, and keepalives cannot be used.

As Stephane has mentioned IDLE is more logically grouped with filtering 
and notifications, which is in phase 2.

I just thought that we add IDLE to profile 1 we bundle too many 
extensions together so that people will be reluctant to implement then 
in servers. I hope I am wrong.
(And personally I don't care, we've just added IDLE to Isode server ;-)).

Alexey