Subject: [lemonade] IMAP resume

From: <[email-masked]>
Date: Thu, 3 Apr 2008 14:02:50 +0300

Hi all,
here is a use case:

You're up in Norway [1], and looking at the "Children of the Earth" monument [2] at the visitor's centre in Nordkapp [3]. Your friends start making fun, so you pull out your camera and you start rolling. At some point you have a recording on your mobile phone's camera. You want to send it to your friends, so you start writing an email. While you are doing this, your friends jump in the car, ready to leave. So, you are left with a draft, which you decide to keep. You jump in the car and move on towards Hammerfest. While You are on the road, the phone will start uploading the draft to the email server. Since You are going through tunnels quite often, your upload will be interrupted every now and then, and since IMAP cannot resume a broken upload, the phone has to re-start uploading from the beginning.

The use case is not specific to Norway, Nordkapp, or the tunnels - it is merely an example. Connectivity issues can occur anywhere, any time.

The problem: a lot of resources (processing power->battery power, air interface bandwidth->the customer's/operators money and time) are wasted as the connection to the server is lost and the client attempts uploading a large content over and over again.
I know that a client should stop after a while (like three retries or something like that and try again later at some point in the future), however if there was a way resume an "upload", it would not have to, becasue the bandwidth would never be wasted.

The situation today:
SMTP does have a CHECKPOINT extension [RFC1845] that allows a broken download to be finished.
In IMAP, the best one can do currently is to slice the content to pieces, upload the pieces, and have CATENATE [RFC4469] reassemble the final piece. This is very resource-consuming on the client.

I was wondering what is the group's opinion about these things:
 - is it worth solving (I think so: a megabyte saved is a megabyte saved)
 - I am not proposing that this should be part of Profile-bis, but if it is worth solving, could it be done in the Lemonade WG? 

Any feedback on these issues is appreciated. Thank You.

References:
[1] http://en.wikipedia.org/wiki/Norway
[2] http://cache.virtualtourist.com/2899504-Children_of_the_Earth-Nordkapp.jpg
[3] http://en.wikipedia.org/wiki/Nordkapp
[RFC1845] http://tools.ietf.org/html/rfc1845
[RFC4469] http://tools.ietf.org/html/rfc4469

Best regards: Zoltán Ördögh
E-mail: zoltan dot ordogh at nokia dot com
Phone: +358 50 386 0566

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

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 13:35:36 +0200

[email-masked] writes:
> Hi all,
> here is a use case:
>
> You're up in Norway [1], and looking at the "Children of the Earth" 
> monument [2] at the visitor's centre in Nordkapp [3]. Your friends 
> start making fun, so you pull out your camera and you start rolling. 
> At some point you have a recording on your mobile phone's camera. You 
> want to send it to your friends, so you start writing an email. While 
> you are doing this, your friends jump in the car, ready to leave. So, 
> you are left with a draft, which you decide to keep. You jump in the 
> car and move on towards Hammerfest.

Probably passing a house where I lived on the way ;)

> While You are on the road, the phone will start uploading the draft to 
> the email server. Since You are going through tunnels quite often, 
> your upload will be interrupted every now and then, and since IMAP 
> cannot resume a broken upload, the phone has to re-start uploading 
> from the beginning.

Yes. TCP tells IMAP the connection was broken, and you really want the 
connection to merely be paused.

> The use case is not specific to Norway, Nordkapp, or the tunnels - it 
> is merely an example. Connectivity issues can occur anywhere, any 
> time.

It's also not specific to IMAP, it applies to any protocol that 
transfers large data items via TCP. You'd have the same issue if you 
use your photo management software to upload pictures while driving.

My gut feeling is that the right place to solve this is TCP. The TCP 
stack on your mobile device would send TCP options to say "ignore 
ten-minute outages" when it opens the TCP conection, and perhaps "I 
just recovered from an outage, please can we resume session 
1234324123421?".

>  - I am not proposing that this should be part of Profile-bis, but if 
>  it is worth solving, could it be done in the Lemonade WG?
>

Hm.

Arnt

---

From: <[email-masked]>
Date: Thu, 3 Apr 2008 15:03:44 +0300

Hi Arnt,
thank You for Your response.
It raises a lot of questions in me.

>My gut feeling is that the right place to solve this is TCP. 
>The TCP stack on your mobile device would send TCP options to 
>say "ignore ten-minute outages" when it opens the TCP 
>conection, and perhaps "I just recovered from an outage, 
>please can we resume session 1234324123421?".

How do we figure out
 - which disconnection is this (in case they are happening frequently)?
 - how many bytes have been successfully received/stored on the server?
 - at which position should the client continue the transmission?
 - what happens if the IP address changes in the meantime (dynamic IP)?
 - what happens if the port number changes in the meantime (NAT)?

I have to agree that if TCP provided a solution for all this, IMAP would
not have to deal with this problem. I think that the SMTP extension was
created for a reason (TCP could not or would not solve this problem?).
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 14:35:22 +0200

>  - which disconnection is this (in case they are happening frequently)?

A connection has to be labelled, say using a 128-bit random cookie. If 
host A says to host B, "I want to resume the connection with cookie 
343241355231423414324134432432412", B can look for a connection with 
that cookie and resume it.

(This is a little simplistic and vulnerable to a MITM attack, but I 
think a more elaborate version of the same scheme is safe.)

> - at which position should the client continue the transmission?

TCP has logic to do that already, it's used to counter packet loss.

>  - what happens if the port number changes in the meantime (NAT)?

It would be possible to tie the new connection to the old using the 
cookie, but I haven't thought about what would happen to software. 
Software may assume that the IP address doesn't change and react badly 
if it does.

> I have to agree that if TCP provided a solution for all this, IMAP 
> would not have to deal with this problem. I think that the SMTP 
> extension was created for a reason (TCP could not or would not solve 
> this problem?).

I don't know why it was created. (I wasn't interested in CHECKPOINT when 
the RFC was written and didn't follow the discussion.)

Arnt

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Apr 2008 14:33:31 +0100

> SMTP does have a CHECKPOINT extension [RFC1845] that allows a broken

See also
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rfc1845bis.html

> In IMAP, the best one can do currently is to slice the content to
> pieces, upload the pieces, and have CATENATE [RFC4469] reassemble the
> final piece. This is very resource-consuming on the client.

Why is it significantly worse than uploading in one unreliable chunk?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH UTSIRE: NORTHERLY BACKING WESTERLY 4 OR 5, INCREASING 6 FOR A TIME.
MODERATE OR ROUGH. RAIN. MODERATE OR GOOD.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: <[email-masked]>
Date: Thu, 3 Apr 2008 17:09:41 +0300

Hi Tony,
thanks for the comments. Good point, but.

>Why is it significantly worse than uploading in one unreliable chunk?

I think that it does not solve the problem - only create several smaller
problems - ; it is an attempt to reduce the amount of bandwidth wasted:
 - smaller pieces->less bandwidth wasted when the connection is lost
 - too small pieces->way too much overhead.

Consider a movie that is 10 megabytes.
We split it to 10 pieces, 1 megabytes each.
We start uploading the first. After transmitting 800k, the connection is
lost. We try again. Next time the connection is lost after we uploaded
10k. We try again, and the connection is lost when we have uploaded
300k. So, we uploaded already over 1 megabytes of data, but we are still
not done with the first piece. After 3 tries, we wait for 10 minutes -
hoping that the network conditions get better - and we try it again. Now
we could upload the first part. We a little over 2 megabytes to get the
1 megabyte on the server.

If we cut to smaller pieces, say 10k. We can significantly reduce the
amount of bandwidth wasted on the connection loss, but it will introduce
significant overhead (protocol chatter+headers).
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Apr 2008 15:23:05 +0100

> significant overhead (protocol chatter+headers).

For 10KB chunks you are talking about maybe 2% overhead. It's possible to
tune dynamically, e.g. you could have an optimistic default (say, 1MB)
that gets reduced if it turns out to be greater than the typical
connection lifetime. I haven't been convinced that you need more protocol
complexity to deal with this problem.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
ROCKALL MALIN HEBRIDES: SOUTHWEST VEERING NORTHWEST 5 TO 7. MODERATE OR ROUGH,
OCCASIONALLY VERY ROUGH LATER. OCCASIONAL RAIN. MODERATE OR GOOD, OCCASIONALLY
POOR.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 16:38:25 +0200

There's also the option of improving the network...

It's not strictly necessary to issue a new address every time a mobile 
enters coverage. The DHCP server can try to give it the same as last 
time.

It's also not strictly necessary to tear down TCP connections the moment 
a mobile loses coverage. The routers can try with ICMP source queches 
for a minute or two.

Have any mobile operators tried such tweaks? Would the problem still be 
unmanageably large after this kind of optimisation?

Arnt

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Apr 2008 15:51:13 +0100

On Thu, 3 Apr 2008, Arnt Gulbrandsen wrote:
>
> It's not strictly necessary to issue a new address every time a mobile enters
> coverage. The DHCP server can try to give it the same as last time.

Though that's no good for users that migrate between GPRS and WiFi etc.

I agree that it's a shame that nowadays TCP tends not to survive network
outages; however the ends of TCP are not the ends of the application so
fully correct failure recovery needs some application-level mechanism.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
BISCAY: EASTERLY 4 OR 5, OCCASIONALLY 6 IN SOUTHWEST. MODERATE. MAINLY FAIR.
MODERATE OR GOOD, OCCASIONALLY POOR IN EAST.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Apr 2008 08:45:02 -0700 (PDT)

> connection to merely be paused.

This is a bug in the sockets-based version of TCP used in UNIX and 
Windows.

This was not a bug in the TCP implemented on the superior operating 
systems of the past, such as TOPS-20 and Multics.

I had long arguments with the UNIX developers back in the 1980s on this 
very issue.  They were far more concerned with aggressively killing 
"abandoned" connections than about preserving connections for mobile 
devices.  And we are still stuck with their deliberate design bugs.

Sadly, only oldtimers who cling to the operating systems of the past know 
the experience of having a network connection resume after a multi-hour 
(even multi-day) outage.

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Tony Finch <[email-masked]>
Date: Thu, 3 Apr 2008 17:19:02 +0100

> This is a bug in the sockets-based version of TCP used in UNIX and

Actually, on UNIX it depends whether the application asks for "keepalive"
(i.e. die faster) probes to be sent. There may be a global setting that
turns the socket option on by default. There's also a question of how
changes in interface state affect higher-level TCBs: e.g. link down, IP
address removal, interface removal. On Unix link-down generally doesn't
reset connections though on Windows it does. The behaviour is often
affected by middleboxes and the peer's TCP. NATs that randomly lose their
connection state tend to make keepalive perferable to recoverable idle
connections.

> the experience of having a network connection resume after a multi-hour

This Unix bigot has experienced idle connection resumption too. It's
particularly nice when it works after your laptop has been to sleep for a
while.

Tony.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 20:02:34 +0200

Mark Crispin writes:
>> Yes. TCP tells IMAP the connection was broken, and you really want 
>> the connection to merely be paused.
>
> This is a bug in the sockets-based version of TCP used in UNIX and Windows.

That's only one of the problems. Routers sending ICMP host unreachable 
as soon as the endpoint loses connectivity away is another, instead of 
dropping the packet and giving the endpoint a little time to come back.

I can't say which problem is more common, but I've seen both problems.

Arnt

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Apr 2008 11:32:10 -0700 (PDT)

On Thu, 3 Apr 2008, Arnt Gulbrandsen wrote:
> That's only one of the problems. Routers sending ICMP host unreachable as 
> soon as the endpoint loses connectivity away is another, instead of dropping 
> the packet and giving the endpoint a little time to come back.

That is also a design bug in sockets.  There is no reason why a TCP stack 
must declare the session to be irrecoverable when an ICMP unreachable 
arrives.  Indeed, I claim that it MUST NOT do so.

As you note, ICMP unreachable just means that something flapped at a 
router.  It says nothing whatsoever about the status of the endpoints; nor 
does it say anything about reachability at any point of time other than 
that specific instant.

TOPS-20 handled it right.  ICMP unreachable caused a TCP open to fail, but 
otherwise did not affect an already-open session.  If the application 
cared, it could find out that an ICMP unreachable happened and/or time out 
the session; but if the application wants to wait, the TOPS-20 TCP stack 
will happily wait until connectivity was restored.

I had something to do that aspect of TOPS-20... ;-)

I spent a long time beating up on UNIX developers about this very issue, 
getting increasing infuriated as I lost IMAP sessions multiple times/day 
due to router flaps.  On at least one system, I had to do a binary patch 
to fix that.  Presently, I convinced most UNIX developers that it was a 
bad idea to kill open sockets due to ICMP unreachable.  Sadly, every so 
often, this ancient issue pops up again when some cretin "fixes" it to do 
so... :-(

-- Mark --

http://panda.com/mrc

---

From: Mark Crispin <[email-masked]>
Date: Thu, 3 Apr 2008 11:54:45 -0700 (PDT)

> connection state tend to make keepalive perferable to recoverable idle

I agree with much of what you say, including the bad behavior of Windows 
and NAT boxes.

However, being the victim of UNIX systems which whack TCBs due to ICMP 
unreachable and/or changes in interface state, I think that you are 
entirely too optimistic about good behavior on UNIX systems.  :-(

-- Mark --

http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 3 Apr 2008 21:31:06 +0200

Mark Crispin writes:
> That is also a design bug in sockets.  There is no reason why a TCP 
> stack must declare the session to be irrecoverable when an ICMP 
> unreachable arrives.  Indeed, I claim that it MUST NOT do so.
>
> router.  It says nothing whatsoever about the status of the 
> endpoints; nor does it say anything about reachability at any point 
> of time other than that specific instant.

I don't really disagree with this, but I think you're overstating it a little.

Anyway. A bit of experimentation by a mobile network operator would be 
very, very good, IMNSHO. Perhaps tweaking DHCP lease extension 
timeouts, NAT timeouts, ICMP packet generation etc. reduces the problem 
to an acceptable level, perhaps not.

Arnt

---

From: <[email-masked]>
Date: Mon, 7 Apr 2008 15:06:26 +0300

Mark,
this sounds great.
But what should we do in the next 10 years until the routers and modern OSes implement TCP properly?

Tony said the overhead introduced by splitting a 10 megs attachment to 1024 (10k each) pieces is only 2% (200k). That does not sound too bad.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Mark Crispin
>Sent: 03 April, 2008 21:32
>To: Arnt Gulbrandsen
>Cc: [email-masked]; Ordogh Zoltan (Nokia-D-MSW/Tampere)
>Subject: Re: [lemonade] IMAP resume
>
>That is also a design bug in sockets.  There is no reason why 
>a TCP stack must declare the session to be irrecoverable when 
>an ICMP unreachable arrives.  Indeed, I claim that it MUST NOT do so.
>
>As you note, ICMP unreachable just means that something 
>flapped at a router.  It says nothing whatsoever about the 
>status of the endpoints; nor does it say anything about 
>reachability at any point of time other than that specific instant.
>
>TOPS-20 handled it right.  ICMP unreachable caused a TCP open 
>to fail, but otherwise did not affect an already-open session. 
> If the application cared, it could find out that an ICMP 
>unreachable happened and/or time out the session; but if the 
>application wants to wait, the TOPS-20 TCP stack will happily 
>wait until connectivity was restored.
>
>I spent a long time beating up on UNIX developers about this 
>very issue, getting increasing infuriated as I lost IMAP 
>sessions multiple times/day due to router flaps.  On at least 
>one system, I had to do a binary patch to fix that.  
>Presently, I convinced most UNIX developers that it was a bad 
>idea to kill open sockets due to ICMP unreachable.  Sadly, 
>every so often, this ancient issue pops up again when some 
>cretin "fixes" it to do so... :-(
>
>-- Mark --
>
>http://panda.com/mrc

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 7 Apr 2008 14:37:21 +0200

> modern OSes implement TCP properly?

First an operator needs to experiment with using source quench, long and 
renewable DHCP leases, and long NAT timeouts.

WLAN access points implement collision avoidance to help TCP, because 
the cost of collisions on WLANs doesn't match the existing TCP model. 
Routers and DHCP servers managing other peculiar networks can help TCP 
work well on their networks, too.

> Tony said the overhead introduced by splitting a 10 megs attachment to 
> 1024 (10k each) pieces is only 2% (200k). That does not sound too 
> bad.

2% is not much, but you have to do the same for each application.

Arnt

---

From: Dave Cridland <[email-masked]>
Date: Mon, 07 Apr 2008 15:42:46 +0100

> just recovered from an outage, please can we resume session

Or TLS:

http://www.usenix.org/event/usenix06/tech/full_papers/koponen/koponen_html/index.html

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade

---

From: Eric Burger <[email-masked]>
Date: Mon, 07 Apr 2008 12:34:43 -0400

Only one question on this thread: can we get back to our WLGC's and not
spend time here reinventing TCP?  Thanks.

Fixing IMAP composition, if it is worth doing, is not going to happen under
our current charter.

> 2% is not much, but you have to do the same for each application.

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
_______________________________________________
lemonade mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lemonade
Supplemental Web Site:
http://www.standardstrack.com/ietf/lemonade