On Fri, Dec 12, 2003 at 09:01:09PM +0100, Anthony G. Atkielski wrote:
The problem is that RFC 3168 postdates all the RFCs that came before it,
and when something needs to be compatible with real-world systems that
are not all instantly and simultaneously upgraded, it needs to behave in
a way that works acceptably with systems that haven't guite reached RFC
3168.
This problem will only get worse, you know. More and more systems on
the Net, with more and more variable maintenance, mean ever greater
difficulty in making any non-backwards-compatible change at all to
anything. For better or for worse, the earliest design decisions of the
Internet will be haunting us for decades to come, and it will be
imperative to design anything new in a way that accommodates them.
Obviously this wasn't done for ECN, and I daresay it isn't being done
for lots of new specifications.
There are a lot of broken firewalls out there. Some of them stop any
new TCP/UDP port that wasn't known about at the time they were
constructed. Should we therefore stop inventing new protocols.
Some of them stop various VOIP stacks. Are they "broken"? Should we
give up on VOIP just because some stupidly designed boxes?
Some middleware boxes reach into TCP packets, and modify them while
they are in flight, either to adjust the Max Segment Size option (to
deal with other breakages caused by things like PPP over ethernet
combined with firewalls that drop ICMP fragmentation needed packets,
which therefore breaks Path MTU discovery), or to adjust the TCP
window size, becuause they are going over satellite links --- and
encryption and integrity protection prevents such hacks from working.
Does that mean that Path MTU was badly designed, because it failed to
take into account stupid firewalls? Does it mean that backwards
compatibility is **SO** important that we cannot add security, lest we
break some badly designed, but yet deployed infrastructure boxes?
Of course, we do need to be pragmatic, which in some cases means
rewarding bad behaviour. But in the case of ECN, most of the major
sites on the net have fixed their broken firewalls. It's unfortunate
that ISOC happens to be one that hasn't, but if we accomodate every
single stupidly designed box out there, we might as well not bother
having IETF meetings, and just pack up and go home. After all, no
matter what we we do, even if it is to design a new protocol that uses
a newly assigned TCP or UDP port, I guarantee *somewhere* out there,
there will be a stupidly designed firewall will not do the right thing
when we deploy that new protocol.
Ultimately, given that market pressure often got us into this kind of
mess, sometimes using market pressure is the only way to get us out of
the mess. It's amazing how quickly most commercial storefront sites
fixed their ECN-buggy firewalls when they realized that they might be
losing potential customers as result of their bogus firewalls....
- Ted