On Sun, 1 May 2005, Edward B. Dreger wrote:
You object to SMTP+AUTH because it isn't standard:
http://www.merit.edu/mail/archives/nanog/199-11/msg00263.html http://www.merit.edu/mail/archives/nanog/199-11/msg00289.html
Neither of these links actually work. But it is "Draft Standard". That is different from saying it is "Standard". It is not "Standard", and is still not "Standard", some 7 years after it went to Draft. All of my criticisms (made presumably in 1999), were correct. In 2005, SMTP AUTH is basically dead. There hasn't been a new mail client supporting SMTP AUTH in many years. What would be the point?
You complain that SMTP+AUTH "doesn't scale"... yet viewing open relay logfiles for abusers scales?! Someone needs to put down the crackpipe.
Actually, it does scale, and very nicely. Its almost trivially easy to automatically spot and block abusers. Blocking scanning prevents open relays from being found. And if they aren't found by open-relay blacklists, they aren't abused and there are no problems whatsoever. This requires almost no attention at all--Just ordinary daily and weekly usage reports, and automated detection and blocking of scans. This is helped along by blocking the blacklists nameservers, so even if they get a message in, it won't get delivered back to them, preventing them from discovering and abusing the relay. By contrast, its much, *much* harder to manage thousands of user accounts and passwords. This requires much customer service attention, and that's expensive. And when you offer backup SMTP service to a corporation for a relative pittance, you don't want to have to take on the headache of keeping all of their usernames and passwords. Many providers run open relays. They don't advertise this fact, due to, well, abusers like Matthew Sullivan. *You* need to put down the crackpipe.
Yet you cite RFC1546 as the One True Anycast. Is RFC1546 a standard? What does its first paragraph say, again?
RFC 1546 is Category: Informational However, its "informational" category doesn't mean one can mislead people into believing that "Vixie-cast" complies with RFC 1546. Calling it "TCP Anycast" and then referring to RFC 1546, misleads people. And criticism is well-deserved. If someone wants to create their own version of Anycast, let them. But they shouldn't mislead people that their version is the same as RFC 1546's version---when in fact they aren't the same. And "Vixie-cast" isn't *anything* like RFC 1546 TCP Anycast. And the fact that they have misled people is probably operational news. Especially since the DNS root server operators also assumed the Vixie was serving as their liason to the IETF, and that the IETF had "blessed" Vixie-cast. Its one thing to setup some random servers with some hairbrained scheme. Its quite another to installed some untested, non-standard, and unapproved configuration on critical network infrastructure like the DNS root nameservers.
DA> You really haven't been paying attention: There's no chance of that at DA> all: It isn't possible to build "vixie-cast" clusters that work around DA> PPLB. There are no topologies which include diverse paths that avoid DA> problems.
http://www.merit.edu/mail/archives/nanog/msg07220.html
Read what I said. Did I say "vixie-cast" clusters? Did I specify a particular topology, or suggest choosing topologies that work?
You said: "As for anycast, there's a fair chance people building anycast clusters will work around PPLB. Maybe they'll build topologies to avoid problems. Maybe they'll have behind-the-scenes unicast intelligence to deal with TCP session transfer." That would be "Vixie-cast" clusters. As I already said, UDP anycast has no problem. And I noted that RFC 1546 TCP Anycast has no problem with PPLB on diverse paths. That leaves only "vixie-cast" clusters. And you also indicated that there might exist a topology involving PPLB on diverse paths that might work. But there isn't one. There isn't any "behind-the-scenes unicast intelligence to deal with TCP session transfer" other than that described by RFC 1546, which involves changes to the TCP stack on each machine, including the client machine. Someone needs to put out their pipe and actually read most of the thread.
Even when the thread is is plain sight for all to reference, you fail to cite correctly. Someone needs to put down the crackpipe.
I cited it correctly.
You claim PPLB over widely diverging paths will become increasingly common. If that actually happened, guess what would happen to unicast TCP?
Nothing much. At worst, a performance problem for older TCP stacks. In stacks that can handle insertions, nothing at all.
Guess what would happen to many UDP-based protocols over unicast?
Nothing whatsoever would happen. A protocol implementation that doesn't behave correctly with out-of-order packets might have a problem. But this is an implementation problem. There is no obligation for an internetwork to deliver packets in order, either. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000