On Fri, Aug 30, 2013 at 06:00:50PM +0000, Terry Gilsenan wrote: > -----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
Hi Terry, Have you tried using a tcp-over-udp tunnel transport? Regards, Ken
