Subject: [lemonade] Profile WG last call

From: "Glenn Parsons" <[email-masked]>
Date: Tue, 25 Oct 2005 11:22:13 -0400

Folks,

This message announces the commencement of the WG last call on the
LEMONADE profile:
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-profile-05.txt

Please review this document paying special attention to:
 - the list of MUST implement features
   (note the editors suggest adding IDLE and $forward to the 
    baseline we agreed in London)
 - the noted open issues

Last call will end 9am on Nov 7th.

Cheers,
Glenn.

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Oct 2005 18:46:15 +0200

>     baseline we agreed in London)

I have a question about this. Since it's a suggestion not done yet, I 
assume there are people who don't want to implement IDLE. I further 
assume that these are clueful people.

The question is then: Why? What counts against IDLE?

(IMO the list is fine, although I'd prefer adding IDLE and $forward. 
We'll implement everything on the list.)

>  - the noted open issues

I think literal+ examples, while perhaps desirable, aren't at all 
important. RFC 2088 will do.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Oct 2005 10:07:31 -0700

> The question is then: Why? What counts against IDLE?

I've implemented IDLE in my server but not in client code.

The big issue with IDLE is that it doesn't work with NAT or any other 
mechanism which depends upon client activity to maintain connectivity.

Verizon's 1xRTT service hangs up after a remarkably short period of 
inactivity, and then calls again when the client issues new activity.  In 
order to make it usable for non-HTTP traffic, I end up running a ping in 
the background to keep it active, or I dial my ISP and deal with the lower 
performance of the analog step.

I don't know if this affects LEMONADE issues.

-- 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 10:23:42 -0700

This sounds like the IDLE time out issues that we observed on 2.5G and 3G networks and that we discussed when comparing with HTTP sessions.

Thanks

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 Mark Crispin
Sent: Tuesday, October 25, 2005 10:08 AM
To: Arnt Gulbrandsen
Cc: [email-masked]
Subject: Re: [lemonade] Profile WG last call

-- Mark --

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 25 Oct 2005 18:53:35 +0100

> important. RFC 2088 will do.

Yes, I've deleted this from the editor's copy. There is a text in the 
document explaining how the existing example can be turned into 
"literal+" example.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Oct 2005 20:04:40 +0200

> document explaining how the existing example can be turned into 

Oh... in that case, why not change it?

Literal+ is mandatory in lemonade. I don't think it really makes sense 
to avoid mandatory features in an example.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Oct 2005 19:44:11 +0100

On Tue Oct 25 18:07:31 2005, Mark Crispin wrote:
> The big issue with IDLE is that it doesn't work with NAT or any 
> other mechanism which depends upon client activity to maintain 
> connectivity.
> 
> 
Agreed, but in those circumstances where either NAT timeouts are set 
to reasonable values, I think IDLE represents a big win, especially 
for mobile:

1) It cuts down the amount of transmission required for the GPRS 
radio in the handset. As I understand it, this is the number one 
battery killer.
2) It's immediately closer to the concept of "Push email". This isn't 
all that important in technical terms, but it does represent a strong 
marketing concept.

If it were down to me, I'd require IDLE, but add a note to the effect 
that if a connection is entirely idle (as in, no data transmitted in 
either direction) for more than a certain, network dependent, length 
of time, then connections passing through NAT and certain stateful 
firewalls may be broken.

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.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Oct 2005 21:21:27 +0200

> 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.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Tue, 25 Oct 2005 12:29:53 -0700 (Pacific Daylight Time)

On Tue, 25 Oct 2005, Arnt Gulbrandsen wrote:
>> 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.

Well, uh,...

Keepalives can also be deadly.  I found that I can not reliably keep an 
ssh session to my server at work over NAT if the ssh server enables 
keepalive.

AFAICT, the cause is that keepalives misinterpret a short-term outage as 
permanent.

-- Mark --

---

From: Dave Cridland <[email-masked]>
Date: Tue, 25 Oct 2005 21:29:13 +0100

On Tue Oct 25 20:21:27 2005, Arnt Gulbrandsen wrote:
>> 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.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 25 Oct 2005 23:21:25 +0200

Mark Crispin writes:
> Keepalives can also be deadly.  I found that I can not reliably keep 
> an ssh session to my server at work over NAT if the ssh server 
> enables keepalive.
>
> AFAICT, the cause is that keepalives misinterpret a short-term outage 
> as permanent.

Depends. On linux, the outage currently has to last about 11 minutes.

But yes, TCP keepalives have disadvantages. TLS keepalives seem better.

Arnt

---

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

BTW,

I think that when we decided to put IDLE in Lemonade profile phase 2 it was for consistency because we plan to discuss push / server to client notification in phase 2. I do not believe that it was because we perceived a problem requiring IDLE.

Stephane

_____
Stephane H. Maes, PhD,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Arnt Gulbrandsen
Sent: Tuesday, October 25, 2005 9:46 AM
To: [email-masked]
Subject: Re: [lemonade] Profile WG last call

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Fri, 28 Oct 2005 19:49:57 +0100

> baseline we agreed in London)

I was going to raise an issue about quality of implementation with 
IMAP BINARY, but then noticed that the IMAP BINARY extension isn't 
actually part of the profile at all.

Given that, for base64 encoded message parts, it represents a saving 
of 25%, I think it should be. Many IMAP servers already implement it, 
and although the base64 growth is somewhat mitigated by some form of 
compression, transmission in binary is going to be better. 
With gzip, for instance, a 145k JPEG compresses to 144k, but encoded 
in base64 is 196k, which compresses to 148k. Comparing gzip with 
BINARY, then, the phone has had to transmit an extra 3k of data, 
which has been encoded twice instead of not at all, presumably a 
waste of CPU resources.

My point was going to be that since one of the more bandwidth-saving 
uses of BINARY in Lemonade is likely to be in sending images from 
camera phones, we need to additionally mandate that APPEND with 
binary content MUST be implemented - some implementations only 
support FETCH ... BINARY, and issue a NO [UNKNOWN-CTE] if they see 
binary content being uploaded.

Dave.