On Wed, 22 Feb 2006, Chris Newman wrote:
> Tony Finch wrote on 2/22/06 0:54 +0000:
>
> > Current securely authenticated message submission requires at least
> > eleven round trips (including TCP startup and shutdown). BURL can
> > reduce this to nine.
>
> I'm glad someone noticed that little feature I slipped into BURL :-)

Yes it is nice, but on reflection I think the way it is specified isn't
ideal. In particular, to quote that bit from RFC 2920 again:

   Additional commands added by other SMTP extensions may only appear as
   the last command in a group unless otherwise specified by the
   extensions that define the commands.

So I think the BURL spec is wrong to talk about pipelining AUTH, and if
you want to allow pipelined AUTH it should be specified as an update to
RFC 2554.

Furthermore, it isn't safe in all situations for a client to pipeline a
single round-trip AUTH. For example, it's common to have dual-purpose MSA
and MX servers which operate in MSA mode after AUTH and MX mode otherwise.
If the client pipelines an AUTH and an intended submission, but the auth
fails, bad things will happen - recipients will be rejected that would
have been OK, an incomplete message will suffer an anti-spam penalty
instead of being fixed up, etc.

Pipelined AUTH is OK if the server is going to reject any un-authenticated
submissions, in which case the server should explicitly say so, perhaps by
using an EHLO keyword line such as 250 PIPEAUTH PLAIN EXTERNAL.

I've also copied this message to Gregory Vaudreuil because of questions
about PIPELINING and BDAT, as well as BURL.

RFC 3030 implies that BDAT can be pipelined, though the way it says so
doesn't follow the "last command in a group" model of RFC 2920.
Furthermore, some of the descriptive text and the example in section 4.2
imply a synchronization point between the envelope and data, though
because all the commands in the sequence can be pipelined, this isn't a
forced sync point. It would be more correct to terminate the envelope
commands with a NOOP to force a sync.

The BURL spec requires a sync point after the "LAST" BDAT or BURL command,
instead of after the message envelope. I think it would be better for BDAT
and BURL to not require any synchronization at all: if the client wants a
sync, it can use the NOOP command. Note that the main reason a sync point
is required after DATA is so that the client and server agree about
whether the next utterance from the client is a command or is message
data. This isn't a problem for BDAT because the command and data are sent
together, with a single response from the server for both.

This would allow a client to pipeline multiple messages together, which
means you can move from using TCP in interactive mode to bulk data mode,
and therefore make the best use of the available bandwidth. For example,
consider a 1Mb/s link with a 100ms RTT. If the client sends a 5KB message,
this takes about 50ms to transmit, so by the time the server's replies
arrive the client will be one or two messages further on; if there was a
problem, the client can deal with it asynchronously, and it will have done
50ms extra useful work. If the client sends a 20KB message, the server's
replies will start arriving part-way through message transmission, so if
there is a problem the client can usefully RSET it before the next chunk
to save time and bandwidth.

I think it would be cool to allow this kind of high-bandwidth asynchronous
message transmission. It is also more friendly from the point of
congestion control than having multiple concurrent SMTP connections
perpetually in TCP slow start.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FAIR ISLE FAEROES: NORTH OR NORTHEAST 4 OR 5, INCREASING 6 IN FAIR ISLE FOR A
TIME, BUT VARIABLE 4 IN FAEROES AT FIRST. FAIR. GOOD.

_______________________________________________
lemonade mailing list
lemonade@ietf.org
https://www1.ietf.org/mailman/listinfo/lemonade