On Fri, 2004-07-09 at 15:17, Greg Connor wrote:
1. Your assertion was that the relationship between SMTP connections and DNS
requests is not linear. This is clearly false. You can admit that was a
mistake, and retract it, or you can explain why you said it. Doing neither
is
called "spreading FUD".
Here is the offending comment that I think you are referring to:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02586.html
: On Wed, 2004-07-07 at 12:31, Alan DeKok wrote:
<snip>
: > Or, do you see Sender-ID as having an amplification problem? e.g.
: > If MARID queries increased super-linearly with the number of
: > connections. If so, it would be a serious flaw in the proposal.
:
: Serious indeed.
:
<snip>
I see this as my agreeing to Alan Dekok's statement. But what you
missed is that there was an amplification problem that Alan overlooked
because he was still using the ASRG assumptions of RFC 2821 information
used to reject messages. He admitted this difference in a subsequent
message. I also started this message by indicating his reference to the
LMAP discussion would be in error because of this, as it effected the
benefit equations. To say I agreed with the statement does not mean I
agreed with his example. I started this message making this concern
explicit. Or so I had thought. : (
It was an example giving by Alan regarding a general concern. I felt
there was an amplification problem that results from the use of the RFC
2822 information and an integrity problem causing repeated data. As the
load on the network increases, a greater amount of data will need to be
repeated. Rejection of messages subsequent to their receipt due to
timeout conditions reaching much abbreviated limits for DNS responses
will lead to this instability. High levels of DNS traffic will
exacerbate such a problem.
The sender of the message may have done nothing wrong, but the data must
be resent adding to the network load. As this load increases, the
amount of traffic that must be resent increases further. I would
describe this a non-linear amplification problem and my reason for
saying "Serious indeed."
Such a change to the amount of UDP traffic will impact the amount of
packet loss, as UDP does not have congestion avoidance. I looked at a
5% packet loss to make a rough estimate of what this could mean with
2. You seem to be implying that UDP packets are more likely to be dropped
than
TCP packets. This is clearly false.
Where do I say this? When the predominate traffic goes from a small
percentage of UDP traffic, to where UDP traffic becomes the prevalent
traffic, there will be a higher rate of packet loss. Unlike TCP, there
is no direct means to signal a lost packet except by the lapse of time.
Unlike TCP, UDP can not detect congestion and resorts to an
exponentially increasing timeout on retries in an effort to avoid packet
loss. This defensive strategy is defeated if the amount of independent
UDP queries exceed network capacity. : (
3. Any hypothetical situation prefixed by "Assume 5% packet loss" is pretty
worthless. 5% packet loss is something to yell at your ISP about, not
something you just assume as part of normal operation.
Yes, 5% would be a rather high level of loss, but I would not blame my
ISP if most of my traffic was mostly UDP. : 0
For Sender-ID, the number of DNS queries added if at the should
not exceed limits, would be 2000 UDP queries. The ratio of UDP queries
to TCP packets, in this case, goes from 0.3 % to 666.0 % of TCP packets.
4. A statement like "666% UDP to TCP ratio" seems to imply that an average
SMTP transaction requires 20 DNS UDP packets, but only 3 TCP packets. Do you
really believe it's possible to deliver a message with only 3 TCP packets?
My
rough guess was at least 14 and usually 20.
This does not change the fact that the payload of UDP traffic went from
.007 % to 225.0 %. Whether there are a few smaller TCP packets is of
minor importance or that the numbers were .01 % to 225 %, I think this
should provide a clear picture of the problem.
So for the TCP traffic of about 400 kbytes, 900 kbytes is used for
the DNS queries. This recommended limit changes the traffic ratio of
UDP/TCP traffic from 0.007 % to 225.0 % at the 666.0 % UDP/TCP
packet ratio.
5. You seem to be assuming that UDP packets have overhead and TCP packets do
not. Also you seem to be assuming that since 20 lookups is the limit, that
it
will also be the average.
It is expressed as a limit. If there are domains permitting this number
of lookups, there is nothing wrong according to the draft. I was
illustrating the absurd levels of UDP traffic the 20 DNS lookups per
message would entail. I had started out using half of this number, but
it did not seem to make an impression. Typically there are 4 DNS
retries for a query where the timeout doubles each time. In an attempt
repair the DDoS problem, the time cap for the entire set of queries was
added to prevent the type of exposure to unknown servers as clarified in
John Levine's tests:
http://www.imc.org/ietf-mxcomp/mail-archive/msg02436.html
6. In practice, mail receivers already do plenty of DNS lookups, including
the
sender domain, the PTR of the IP, its corresponding A, the MX of the
purported
sender, one or more DNSBLs and/or RHSBLs. You don't appear to be taking this
into account. It is unrealistic to expect an SMTP transaction to be accepted
with "only one" DNS lookup.
Yes, there will be queries to RBLs in most cases and a few other DNS
checks. RBL checks are to known servers that are often fairly robust.
This fully misses the concern raised however, as none of these normal
checks will cause good messages to be repeated. Nor will these rise to
a level of UDP requests that may overwhelm network traffic with respect
to payload, as it can for Sender-ID.
-Doug