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