Re: Mail Path MTU discovery?

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.