In message <20190303184645.gl...@straasha.imrryr.org>, Viktor wrote:
>I could also point out that TCP stacks can allow the same local >ephemeral port to be used for multiple TCP connections, provided >the 4-tuple (remote ip, remote port, local ip, local port) is unique. >There is no requirement that just the local ports of established >TCP connections be distinct. This answers my original and most fundamental question, and confirms what I believed I already knew about the potential for simultaneous local IPv4 port reuse. So thanks for that. >Well, it seems that you only knew the empirical conclusions. Had you >known how Postfix ensures performance under load, you'd have refuted >the other fellow's false scenario without coming to the list. Well, when arguing (e.g. on a mailing list) with someone who consistantly drops down into the classic retorical "appeal to authority" mode (as in: "I know, you don't, and you are an idiot, so STFU!') it is usually best to get a pronouncement from a a different authority having a different view, if the goal is to refute the false "appeal to authority" being put forward. So I came here. I personally don't know off the top of my head any folks who are more widely considered "authorities" on how mail servers can and should work than you and Wietse. >> I still would like to know if the total number of outbound SMTP connections >> which Postfix may have open, at any one given point in time, may or may not >> exceed 65536. > >This is a silly question. Typical message delivery latency can be >estimated at around 1s. A hypothetical server running at a concurrency >of 64k connections would be pumping out 64k msgs/sec, but the Postfix >queue manager and the disk are very unlikely to go that fast. >Realistically, a single email server may be able to deliver at best >O(1000) msgs/sec. > >At a hypothetical sustained 64k messages per second, a server would >be able to deliver around 5.6 billion messages a day. That's not >a realistic load for a single machine, either inbound or outbound. > >Real servers handle smaller loads with outbound concurrency limits >in the hundreds or a few thousand. With Postfix brief input spikes >that exceed the output rate lead growth in the size of the queue >without unbounded demand for CPU and network. > >There are also caps on concurrent incoming connections, and >sufficiently high input rates will reduce opportunities for new >connections, forcing some or most senders to defer delivery. That's >what horizontal scaling is for, with anycast IPs to spread the load >geographically, and in-datacentre load-balancers to further spread >the load among multiple machines, ... Well, but see, this is precisly what the argument was/is about. As soon as you start talking about load balancers, you are also taking about more than one IP address. It was and is my contention that even great vast gobs of outbound email can be handled on a single IPv4 address, *if* one is doing it "right". And by "right" in this context, I mean having a great big pipe into the machine in question, having the machine itself be something killer, like fer instance a 32-core Ryzen or something, and having the "disk" be something like a 1TB NVME stick, or maybe even... dare I say it?... Optane! Basically, my central thesis in this other conversation that I'm having elsewhere is that current usage norms when it comes to (finite and vanishing) IPv4 addresses are, by and large, exceptionally wasteful and that allocation policy should be adjusted accordingly. My opponents in this debate have used and are using mutiple (mostly lame) arguments for why they need lots and lots of IPv4 addreses. I was able to rather easily shoot down most of those (obviously lame) arguments on my own, but when it came to this question of how many simultaneous outbound mail sessions could dance on the head of a single IPv4 address, I had to ask for some help.... which I believe I have now, mostly, gotten. (Thank you.) Regards, rfg
