[dns-operations] The trouble with SCTP.

[Douglas Otis]

On 2/3/10 5:41 AM, Paul Vixie wrote:
> so far so good.  surprisingly few stateful firewalls blast away TCP options
> especially the ones that require an extension that puts some of them where
> the payload usually is.
>
> in testing thus far, this stuff gets through when UDP/53 does not and when
> a new protocol like SCTP (which i'd otherwise have preferred) would not.
>    
With increased use of memory w/o ECC, and TCP's inability to detect ~2% 
the packets affected by bus interface issues means having an option for 
something other than TCP or UDP is needed to improve data integrity.

For some background, I was working within a storage forum, where a major 
OS vendor developing network attached storage using TCP made their 
presentation.  When asked during the meeting how they recovered from 
protocol incoherency states, their response was remarkable.  "We have 
found customers would rather have bad data than no data."  When then 
asked whether logs might indicate the frequency of such occurrences, 
"No. Our customer support would be unable to handle the resulting 
support calls."  After some astonishment at the honesty of these 
answers, someone then exclaimed. "I hope you're not doing this for a 
bank."  The engineer proudly exclaimed, "This is being used by Bank of 
America."

At the IETF meeting in Hiroshima, I asked Joe Touch about TCP's 
inability to detect commonly occurring errors.  His reply was that TCP 
is not responsible for telco bit error rates, saying its a problem that 
must be dealt with at the physical interface.  I attempted to explain 
that the concern was not related to telco bit error rates, but rather 
was related to TCP's error detection algorithm having the modulo of 
common error modes.  He then said that TCP includes an option for 
different error checks, but of course that would set the clock back more 
than a decade, without resolving other fundamental issues related to TCP 
DDoS and transactional security.

At the prior IETF meeting, the Internet Journal distributed in Stockholm 
included misinformation related to SCTP as not being suitable for high 
volume applications with statements based upon quotes more than 6 years 
old.  The impression made ignored availability of commodity NICs that 
offload SCTP at 10Gb/s and 1Gb/s,  and processors with math coprocessors 
able to calculate CRC32c over a block of data by a single instruction.  
CRC32c also extends error protection for Jumbo frames with its increased 
Hamming distance over that of the Ethernet CRC.

If a standards body or government were to mandate use of SCTP for 
critical infrastructure, such as electrical grid control or DNS, then 
CPE equipment unable to support DNS over TCP would actually be in a 
better position to support SCTP since it offers assured framing while 
allowing unreliable unordered delivery.  This mode would not require 
caching to handle PMTU issues, while still ensuring transaction 
integrity.  ISPs could offer standard DNS resolvers to keep legacy 
equipment functional during the transition.

Looking for partial TCP related solutions during disruptive changes 
caused by IPv6 tunneling or DNSSEC misses an opportunity to usher in a 
better foundation for creating a safer Internet.  The transitional goals 
should consider what is required to ensure stability and integrity at 
the ISP first.  There will be time to resolve last mile issues later.  
Some have complained that SCTP frames are too complex compared to TCP's 
nebulous byte stream.  However, this framing allows immediate placement 
of data in most cases, even within chained queries and responses.

-Doug