-----Original Message----- From: owner-postfix-us...@postfix.org [mailto:owner-postfix-us...@postfix.org] On Behalf Of Robert Sander Sent: Saturday, 31 August 2013 3:47 AM To: postfix-users@postfix.org Subject: Re: Re-inventing TCP (was: newbie check..)
>Am 30.08.2013 19:36, schrieb Terry Gilsenan: >> The killer on high latency links is the tcp-window and the continual >> wait for ack. With links above 1000ms this compounded delay reduces >> the available bandwidth to a very small percentage of the interface >> speed (eg:256kbps on a 2mbps link). Without this I have seen UDP data >> streams that will approach the actual interface speed. (eg: 1.8mbps on >> a 2mbps link) > >That may be true. But SMTP is an non-interactive, non-realtime application >that does not need high bandwidth. Keep the servers talking to each other >until the >email is reliably transferred over TCP. Yeah, you know that, and I know that, but users that are connected with a 1mbps vsat link (with varying latency between 900ms and 1300ms) who then attach a 20mb document to an email and click send, cannot understand why it takes 45 minutes to deliver. That same 20mb over UDP will only take a couple of minutes, and in reality does not use any more bandwidth. When you extrapolate that by say 50 users sharing that 1mbps vsat link, and all of them using SMTP to send attachments of various sizes, saying be patient simply doesn't work because the tcp-window makes the link very inefficient, and a given the cost of vsat bandwidth (in the region of US$5k/mbps/month), just buying more is not a sensible option either. (not to mention the infrastructure cost escalation with higher upload speeds) I think the implementation of an additional feature that will open a UDP stream for bulk data in parallel to the TCP connection through which the SMTP transaction is happening is workable. Other protocols do a similar thing, so it is more along the path of embrace and modify than to re-invent the wheel. T ===[Disclaimer]=== This electronic transmission, including any attachments, is confidential, may contain privileged information and should be read or retained only by the intended recipient. If you received this message in error, please delete it from your system and notify the sender immediately. Any review, dissemination or other use of this information by persons or entities other than the intended recipient is strictly prohibited. ===[End]===
