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.