This exchange is rather interesting, since it seems to focus on my system, which failed to get a useful connection at one point in time, but did get one the next day when I tried it again, without making any changes. So, now it is argued that I need to fix my system. It has also been stated that it Is time for me to change ISP PROVIDER. I can think of lots of reasons to do so, if I could find one that is worth the effort and disruption. I don't really believe other IP providers are all that much better. I already pick up and post my mail with another small ISP, that I really trust. So, what is this ECN stuff all about, that I should understand and deal with? Quite frankly, I am amazed at how much diagnosis you all have done without knowing much of anything about my system, or my connection and service provider. Am I to understand that Verizon is engaged in some kind of dastardly business of unhinging the Internet? It seems that my withdrawal from IETF participation after the Chicago meeting (which blessed ICANN -- For Shame!) leaves me at some kind of technical disadvantage, though I doubt that continued travel to IETF meetings would have been of any value at this point, so I do not plan to resume. So, you can all relax;-)... I am not coming back, not even to San Diego where I could just commute from home. Now, I sometimes find that my use of an Opera Browser causes some of my connections to fail on my MAC OS.9.2.3 OS. I am looking to update to a new OS-10... in the near future, but as I am retired, I am not rushing to spend the money;-)... Certainly not because of this flapping discussion... Cheers...\Stef At 19:51 +0100 12/11/03, Anthony G. Atkielski wrote: >Simon Leinen writes: > > > Yes, of course. Stef's not at fault here - www.isoc.org should be > > fixed to tolerate ECN (or, even better, support it). > >No, Stef's system should be modified to establish connections without >ECN if a connection with ECN is immediately reset. > >It should be obvious that correcting the local system allows access to >thousands of additional remote systems, whereas change one remote system >allows access only to that one additional remote system. > >Expecting all systems to change to accept ECN is like expecting everyone >to jump to IPv6 just because one's local system uses it. > > > ... such as ECN (Explicit Congestion Notification) - which > > was designed to be simple and backwards compatible ... > >If it were backwards compatible, it would not be setting reserved bits >unconditionally. A backwards-compatible behavior is always 100% >transparent to hosts that do not understand or support that behavior. > >Let's try an illustrative example. Suppose you want some sort of login >that will work with both SSH and Telnet. The proper way to do this is >to write a client that first attempts to connect with SSH (the >equivalent of setting reserved bits in the ECN example). If the remote >host refuses the SSH connection, the proper behavior is to then fall >back to Telnet, and establish a Telnet connection. This is fully >backwards-compatible. If you build the client to establish only SSH >connections, it is NOT backwards-compatible, because remote hosts that >do not support SSH will be unable to communicate with your local system >at all. > >ECN needs to work the same way. First you try with ECN. If the remote >host immediately resets the connection, you disable ECN completely and >try again. You may not have ECN if you then succeed, but at least you >will have a connection. That's backwards-compatibility. > >In summary, the host that needs to be fixed here is the Linux or other >host that insists on ECN and tolerates nothing else. Unless your system >MUST have ECN supported for all connections for some reason, trying to >force it unconditionally is very unfriendly and incompatible behavior. >Until and unless the entire planet upgrades to support ECN, you're >locking yourself out of a fair percentage of sites.