Subject: [Andrew Rutherford <[email-masked]>] Re: Resume command for ESMTP?

From: Franck Martin <[email-masked]>
Date: 06 Aug 2001 20:32:33 +1200

I'm not sure if this message reached the lists... I'm not a subscriber
of ietf-smtp, may be I should?

However, my comments, is that I had a look at "SMTP Service Extension
for Checkpoint/Restart" RFC 1845, which is Experimental. My guess is
that this RFC would need a review and may be moved to the standard
track...

I would like comments on the way I though about it, and the way it is
presented, what do you think of the 2 methods?

in RFC 1845
The server send CHECKPOINT to the EHLO command, then the client in the
MAIL FROM adds TRANSID with a transaction ID, which the server answers
with ok or with a number of byte to resume from.

In what I envisaged
The server send RESUME to the EHLO command, then the client before DATA
send the RESUME command (with or without a session ID) which the server
answer by a SESSION with a session ID and a number of Bytes to resume
from (or 0 to start from the beginning again). 

I feel in the last system letting the server give the session ID to the
client ensure that the session ID is unique on the server, and that the
client learn about the session ID only if it has tried before to send
the message.

So let me know where to go from there...

Cheers
[email-masked]

Subject: Re: Resume command for ESMTP?
From: Andrew Rutherford <[email-masked]>
To: [email-masked], Franck Martin <[email-masked]>
Date: Mon, 6 Aug 2001 11:03:54 +0930

At 8:09 PM -0400 5/8/01, [email-masked] wrote:

>Am taking further followups to [email-masked] where it belongs...

Seems reasonable, but I'm not subscribed, so I won't forward to that 
list. Please feel free to forward any extracts you think relevant.

>Is there any evidence that it is common enough to have a network outage severe
>enough that the TCP connection gets broken, but that within 5 minutes it's
>resumable?

Well, I do some contracting in Papua New Guinea. The whole country is 
fed by a 4M satellite circuit, which is usually right up on the 100% 
utilisation mark. Large email messages take a long time to get 
through.

Now, being in tropical latitudes, there are often rainstorms up here. 
BIG rainstorms. Rainstorms so big that occasionally even the 17m 
satellite dishes can no longer receive traffic.

In the wet season, one sometimes gets 10 or so outages of 2-5 minutes 
each over a period of a few hours. Most TCP sessions will drop if 
they're trying to push traffic unsuccessfully for over two minutes.

(You can sometimes get similar outages with a smaller window over 
long-haul microwave networks around sunrise/sunset.)

Given that Franck is in Fiji, I expect he sees similar issues.

>Well.. I still think that the *proper* solution is to fix the TCP 
>infrastructure
>so that there isn't a NEED for a RESUME....

No fibre across the sea floor so physical infrastructure can't be 
fixed short term, and realistically I think that in the face of no 
other information TCP is doing the right thing in dropping the 
connection.

Having an upstream mail server listed in MX's with parameters tuned 
to the link would help, except that most implementations only try 
higher MX's if the connection fails, not if the session fails, and 
will keep reconnecting to the lower MX'd server. This is usually 
solved with access lists preventing the outside from connecting 
directly across the satellite, forcing connectivity to the server 
tuned (larger TCP disconnect timers, among others) to forward 
correctly over the link.

-- 
Andrew Rutherford  [email-masked]  http://www.iagu.net/  +61 414 313 767
Iagu Networks      PO Box 256        Rundle Mall SA 5000   Australia

---

From: [email-masked]
Date: Mon, 06 Aug 2001 08:06:09 -0700 (PDT)

> that this RFC would need a review and may be moved to the standard

Why? The specification is there. Nothing prevents you from using an
experimental specification, so if it solves your problem by all means implement
it.

The purpose of having experimental specifications is to gain experience. Unless
there are implementations that demonstate this extension's value there's
effectively no chance of it or anything like it being placed on the standards
track.

> presented, what do you think of the 2 methods?

I think there needs to be a compelling reason to change from what's already
specified. And regardless of this, there needs to be substantial implementation
experience and demonstration of worth before moving any scheme to the standards
track.

> client learn about the session ID only if it has tried before to send

Generating unique ids is totally trivial for either a client or a server,
so this isn't a valid concern IMO.

				Ned

---

From: Simon Leinen <[email-masked]>
Date: 07 Aug 2001 12:11:18 +0200

Note that there's also the PIPELINING extension (RFC2920), which helps
a lot with *small* messages over paths with loss or large RTTs, by
reducing the number of "turns" in the SMTP conversation, and thus the
number of packets.

If you want to improve e-mail connectivity for people in poorly
connected places, it would be a good idea to add PIPELINING support to
your favorite MTA if it isn't there already (btw. I've done this for
Smail when this was my favorite MTA, and I think Ned has already done
the same for his).

For huge messages, PIPELINING doesn't help that much, but other people
have pointed to existing mechanisms that do.
-- 
Simon.