On 13-feb-04, at 18:56, Hadmut Danisch wrote:
I wonder whether it would be desirable to use similar
algorithms as for IP routing for Mail Path MTU discovery.
I already listed the goal that users want to be able to exachange files
of arbitrary size, even when service providers limit the size of
messages or the user's inbox. The key part here is that files should be
split into several messages, and the transmission of these messages
that hold part of a file is controlled end-to-end so that none of the
intermediate buffer space overflows.
The reason that we use PMTUD in IP is that per-packet handling is
relatively expensive compared to the transport of user data, so packets
should be as large as possible. I don't think this applies to email in
the same way. Obviously there is _some_ additional overhead when
sending a file as 100 100k messages rather than 10 1MB messages, but on
the other hand there are also significant disadvantages of using larger
messages: when something goes wrong in the middle there is more to
resend, head of line blocking...
So I would say: set a fixed maximum message size. On the other hand, if
we consider Moore any size that seems reasonable now (such as 1MB) will
probably be way too small in 10 - 20 years when computing power is 100
to 10000 times what we have now. So maybe we indeed need this.
Example: Before sending the 5 GByte E-Mail, a short control
message could be sent to the recipient, where every relay
can reduce the maximum Mail size. Then the message is sent back.
This would of course not be a guarantee, since the path can
change every second. But it's at least a hint and could avoid
the 5 GByte to be sent just for generating an error message.
This makes sense, but I think we can go a little further and see
whether it's necessary to push large messages and especially files out
to the recipient's inbox anyway, why not just send a light-weight
message indiciating the availability of the "real" message or the file
in question, and then the receiver can connect to the place where the
message/file is stored and then the file is transmitted to the place
where it needs to be directly. Additionaly, we can add an optional
proxy layer here, allowing for extremely efficient distribution of
binary information through mailinglists.
So a software maker could send out a message with attached a file that
contains a large update to all their customers. The customers all
receive the message and then proceed to download the file, if they want
to have it, through their ISP's proxy. This should save big time on
disk space and bandwidth for ISPs.