> In the UK two of the largest ISPs - BT Internet and Freeserve - have
> ECN-blocking
> firewalls. So does theregister.co.uk for that matter. If I enable ECN
> I lose
> the ability to send emails to a huge percentage of the people on the
> mailing lists
> that run on my machine.
>
> These ISPs
> > So, no reason for a firewall author to check these bits.
>
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.
If you care about such things you run pure proxy. A packet
> > RFC793, where is lists the unused flag bits as "reserved".
> > That is pretty clear to me. It just has to say that
> > they are reserved, and that is what it does.
> >
>
> Is the definition of "reserved" defined anywhere? In a lot of specs,
> "reserved" means MBZ.
>
> Note, that I'm not
In the UK two of the largest ISPs - BT Internet and Freeserve - have
ECN-blocking
firewalls. So does theregister.co.uk for that matter. If I enable ECN
I lose
the ability to send emails to a huge percentage of the people on the
mailing lists
that run on my machine.
These ISPs will
Chris Meadors wrote:
>
> On Fri, 26 Jan 2001, Daniel Chemko wrote:
>
> > Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
> > microsoft.com...
>
> It's down, ha ha, Microsoft is down! I'm joking of course. But you don't
> know how many times my techs have told
"Randal, Phil" wrote:
>
> James Sutherland wrote:
>
> > Except you can't retry without ECN, because DaveM wants to do
> > a Microsoft and force ECN on everyone, whether they like it
> > or not. If ECN is so wonderful, why doesn't anybody actually
> > WANT to use it anyway?
>
> And there's the
"Randal, Phil" wrote:
James Sutherland wrote:
Except you can't retry without ECN, because DaveM wants to do
a Microsoft and force ECN on everyone, whether they like it
or not. If ECN is so wonderful, why doesn't anybody actually
WANT to use it anyway?
And there's the rub. Whether
Chris Meadors wrote:
On Fri, 26 Jan 2001, Daniel Chemko wrote:
Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
microsoft.com...
It's down, ha ha, Microsoft is down! I'm joking of course. But you don't
know how many times my techs have told me that.
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
>
> We are not talking about attacks here, we are
Dax Kelson wrote:
> Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
>
> > Does ECN provide perceived benefits to the node using it?
>
> Why are you even making suggestions when you haven't even read the RFC?
>
> It seems that knowing what ECN is would be prerequisite to engaging in
>
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
> ...
> > An attack against an Xray system is much more likely to come from inside the
> > companies network.
> ...
> We are not talking about attacks here, we are
On Sat, 27 Jan 2001, Gregory Maxwell wrote:
> On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
> > On Sat, 27 Jan 2001, David Schwartz wrote:
> >
> > >
> > > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > > policy management. In such a
On Sat, 27 Jan 2001, Gregory Maxwell wrote:
On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
On Sat, 27 Jan 2001, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
...
An attack against an Xray system is much more likely to come from inside the
companies network.
...
We are not talking about attacks here, we are talking
Dax Kelson wrote:
Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
Does ECN provide perceived benefits to the node using it?
Why are you even making suggestions when you haven't even read the RFC?
It seems that knowing what ECN is would be prerequisite to engaging in
discussion
On Sun, Jan 28, 2001 at 01:57:53PM +0100, Dominik Kubla wrote:
On Sat, Jan 27, 2001 at 11:35:43PM -0500, Gregory Maxwell wrote:
...
An attack against an Xray system is much more likely to come from inside the
companies network.
...
We are not talking about attacks here, we are talking
On Sun, Jan 28, 2001 at 02:10:25AM +0100, Dominik Kubla wrote:
> On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote:
> > It's this kind of ignorance that makes the internet a less secure and stable
> > place.
>
> You have obviously absolutely no idea what you are talking about.
> On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > > Firewalling should be implemented on the hosts, perhaps with
> > > centralized
> > > policy management. In such a situation, there would be no
> > > reason to filter
> > > on funny IP options.
> > That's madness. If you
Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
> Does ECN provide perceived benefits to the node using it?
Why are you even making suggestions when you haven't even read the RFC?
It seems that knowing what ECN is would be prerequisite to engaging in
discussion about it.
Dax
-
To
In message <[EMAIL PROTECTED]> you write:
> I thought that most firewalls were supposed to be insanely paranoid.
> Perhaps it would be considered a possible covert data channel, as
> farfecthed as that may sound.
If they were `insanely paranoid' they wouldn't just be doing packet
filtering. The
On Sat, 27 Jan 2001, Frank v Waveren wrote:
> Why? Why not just zero them, and get both security and compatibility...
>
the problem is that you don't know what they mean, just zeroing them may
break things (how will the sender know that you zeroed them).
David Lang
-
To unsubscribe from this
On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
> On Sat, 27 Jan 2001, David Schwartz wrote:
>
> >
> > > Firewalling should be implemented on the hosts, perhaps with centralized
> > > policy management. In such a situation, there would be no reason to filter
> > > on funny IP
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
>
> That's madness. If you have to implement
On Sat, 27 Jan 2001, David Schwartz wrote:
>
> > Firewalling should be implemented on the hosts, perhaps with centralized
> > policy management. In such a situation, there would be no reason to filter
> > on funny IP options.
>
> That's madness. If you have to implement your firewalling
> Firewalling should be implemented on the hosts, perhaps with centralized
> policy management. In such a situation, there would be no reason to filter
> on funny IP options.
That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to
On Sat, Jan 27, 2001 at 08:58:51PM +0100, Jamie Lokier wrote:
[snip]
> > I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
> > on 'hide nat'ed connections. This causes unreasonable stalls for users on
> > SACK enabled clients. Not cool.
>
> If both SACK and
Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
>
> Eeek! NO NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that wouldn't have worked that way..
>
> I
On Sat, Jan 27, 2001 at 02:20:32PM -0500, Gregory Maxwell wrote:
> > Why? Why not just zero them, and get both security and compatibility...
> Eeek! NO NO NO NO NO NO NO NO!
> For ECN that would have worked, but that doesn't mean that something
> couldn't have been implimented there that
On Sat, Jan 27, 2001 at 07:18:09PM +0100, Frank v Waveren wrote:
> On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
> > Practice being really, really paranoid. Think: You're designing a
> > firewall; you've got some reserved bits, currently unused; any future code
> > that uses them
In article <[EMAIL PROTECTED]> you wrote:
>> Think of yourself as a firewall author now. You come across this, and
>> go, "these bits aren't used now; this means noone should be setting
>> them. I have no guarantee that anything in the future isn't going to use
>> these bits for something that
On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
> Practice being really, really paranoid. Think: You're designing a
> firewall; you've got some reserved bits, currently unused; any future code
> that uses them could behave in completely arbitrary and insecure ways,
> for all you
H. Peter Anvin wrote:
> "David S. Miller" wrote:
> >
> > H. Peter Anvin writes:
> > > Last I communicated with them, I looked for a reference like that in the
> > > standards RFCs so I could quote chapter and verse at the Hotmail people,
> > > but I couldn't find it.
> >
> > RFC793, where is
On Fri, Jan 26, 2001 at 04:59:13PM -0500, Michael H. Warfield wrote:
> No... Microsoft learned, just two days ago, something that has
> been part of best practices for over 15 years. Do NOT put all of your
> DNS servers on the same network! The technical error may have triggered
> the
> Hotmails failing machines, for example, send RST packets back when
> they see ECN. Ignoring valid TCP RST frames is unacceptable and
> Linux will not do that as long as I am maintaining it.
Whadda word!
---
Woah... I did a "cat /boot/vmlinuz >> /dev/audio" - and I think I heard
god...
-
To
> Every single connection to ECN-broken sites would work as normal - it
> would just take an extra few seconds. Instead of "Hotmail doesn't
> work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
> use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
I
Every single connection to ECN-broken sites would work as normal - it
would just take an extra few seconds. Instead of "Hotmail doesn't
work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
use Yahoo". A few million of those, and suddenly Hotmail isn't so hot...
I think
Hotmails failing machines, for example, send RST packets back when
they see ECN. Ignoring valid TCP RST frames is unacceptable and
Linux will not do that as long as I am maintaining it.
Whadda word!
---
Woah... I did a "cat /boot/vmlinuz /dev/audio" - and I think I heard
god...
-
To
On Fri, Jan 26, 2001 at 04:59:13PM -0500, Michael H. Warfield wrote:
No... Microsoft learned, just two days ago, something that has
been part of best practices for over 15 years. Do NOT put all of your
DNS servers on the same network! The technical error may have triggered
the
H. Peter Anvin wrote:
"David S. Miller" wrote:
H. Peter Anvin writes:
Last I communicated with them, I looked for a reference like that in the
standards RFCs so I could quote chapter and verse at the Hotmail people,
but I couldn't find it.
RFC793, where is lists the unused
On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
Practice being really, really paranoid. Think: You're designing a
firewall; you've got some reserved bits, currently unused; any future code
that uses them could behave in completely arbitrary and insecure ways,
for all you know.
In article [EMAIL PROTECTED] you wrote:
Think of yourself as a firewall author now. You come across this, and
go, "these bits aren't used now; this means noone should be setting
them. I have no guarantee that anything in the future isn't going to use
these bits for something that isn't
On Sat, Jan 27, 2001 at 07:18:09PM +0100, Frank v Waveren wrote:
On Sat, Jan 27, 2001 at 04:10:48AM +, David Wagner wrote:
Practice being really, really paranoid. Think: You're designing a
firewall; you've got some reserved bits, currently unused; any future code
that uses them could
On Sat, Jan 27, 2001 at 02:20:32PM -0500, Gregory Maxwell wrote:
Why? Why not just zero them, and get both security and compatibility...
Eeek! NO NO NO NO NO NO NO NO!
For ECN that would have worked, but that doesn't mean that something
couldn't have been implimented there that wouldn't
Gregory Maxwell wrote:
Why? Why not just zero them, and get both security and compatibility...
Eeek! NO NO NO NO NO NO NO NO!
For ECN that would have worked, but that doesn't mean that something
couldn't have been implimented there that wouldn't have worked that way..
I think that
On Sat, Jan 27, 2001 at 08:58:51PM +0100, Jamie Lokier wrote:
[snip]
I think that older Checkpoint firewalls (perhaps current?) zeroed out SACK
on 'hide nat'ed connections. This causes unreasonable stalls for users on
SACK enabled clients. Not cool.
If both SACK and SACK_PERMITTED were
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.
That's madness. If you have to implement your firewalling on every host,
what do you do when someone wants to run a
On Sat, 27 Jan 2001, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.
That's madness. If you have to implement your firewalling on every
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.
That's madness. If you have to implement your
On Sat, Jan 27, 2001 at 11:09:27PM +, James Sutherland wrote:
On Sat, 27 Jan 2001, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with centralized
policy management. In such a situation, there would be no reason to filter
on funny IP options.
On Sat, 27 Jan 2001, Frank v Waveren wrote:
Why? Why not just zero them, and get both security and compatibility...
the problem is that you don't know what they mean, just zeroing them may
break things (how will the sender know that you zeroed them).
David Lang
-
To unsubscribe from this
In message [EMAIL PROTECTED] you write:
I thought that most firewalls were supposed to be insanely paranoid.
Perhaps it would be considered a possible covert data channel, as
farfecthed as that may sound.
If they were `insanely paranoid' they wouldn't just be doing packet
filtering. The
Jamie Lokier said once upon a time (Fri, 26 Jan 2001):
Does ECN provide perceived benefits to the node using it?
Why are you even making suggestions when you haven't even read the RFC?
It seems that knowing what ECN is would be prerequisite to engaging in
discussion about it.
Dax
-
To
On Sat, Jan 27, 2001 at 02:18:31PM -0800, David Schwartz wrote:
Firewalling should be implemented on the hosts, perhaps with
centralized
policy management. In such a situation, there would be no
reason to filter
on funny IP options.
That's madness. If you have to implement
On Sun, Jan 28, 2001 at 02:10:25AM +0100, Dominik Kubla wrote:
On Sat, Jan 27, 2001 at 07:11:59PM -0500, Gregory Maxwell wrote:
It's this kind of ignorance that makes the internet a less secure and stable
place.
You have obviously absolutely no idea what you are talking about. Period.
> "David" == David Wagner <[EMAIL PROTECTED]> writes:
David> Practice being really, really paranoid. Think: You're
David> designing a firewall; you've got some reserved bits,
David> currently unused; any future code that uses them could
David> behave in completely arbitrary
Helge Hafting wrote:
>So, no reason for a firewall author to check these bits.
You don't think like a firewall designer! :-)
Practice being really, really paranoid. Think: You're designing a
firewall; you've got some reserved bits, currently unused; any future code
that uses them could behave
>> We may be right, "they" may be wrong, but in the real world
>> arrogance rarely wins anyone friends.
>
> So you also turn of PMTU and just set the MTU to 200 bytes
> because broken firewalls may drop ICMP ?
Nah, you don't need to go that low. Try 1200 or 1400 instead.
-
To unsubscribe from
Dominik Kubla wrote:
>
> On Fri, Jan 26, 2001 at 04:27:07PM +0100, Jamie Lokier wrote:
> ...
> > Yeah, Apache and Samba establish _outgoing_ connections with fixed
> > source ports Not!
>
> Oops! Of course. Brain-damage on my part. Now where is that dammned
> brown paper bag...
>
ftpd
On Fri, Jan 26, 2001 at 01:52:26PM -0800, Stuart Lynne wrote:
> In article <[EMAIL PROTECTED]>,
> James Sutherland <[EMAIL PROTECTED]> wrote:
> >On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> >Except you can't retry without ECN, because DaveM wants to do a Microsoft
> >and force ECN on
In article <[EMAIL PROTECTED]>,
James Sutherland <[EMAIL PROTECTED]> wrote:
>On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
>Except you can't retry without ECN, because DaveM wants to do a Microsoft
>and force ECN on everyone, whether they like it or not. If ECN is so
No, he just wants them to
"Randal, Phil" wrote:
> James Sutherland wrote:
>
> > Except you can't retry without ECN, because DaveM wants to do
> > a Microsoft and force ECN on everyone, whether they like it
> > or not. If ECN is so wonderful, why doesn't anybody actually
> > WANT to use it anyway?
>
> And there's the rub.
On Fri, 26 Jan 2001 15:29:51 +, James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.
Who's forcing? You have to *SPECIFICALLY* enable it in the config,
ignoring the notice in the help
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in
On Fri, 26 Jan 2001, Daniel Chemko wrote:
> Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
> microsoft.com...
It's down, ha ha, Microsoft is down! I'm joking of course. But you don't
know how many times my techs have told me that. It's either that, or
something
Microsoft are bad for dropping ICMP because of security.. .I mean try pinging
microsoft.com...
James Sutherland wrote:
> On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
>
> > On 2001-01-26T16:04:03,
> >"Randal, Phil" <[EMAIL PROTECTED]> said:
> >
> > > We may be right, "they" may be wrong,
On Fri, Jan 26, 2001 at 06:37:12PM +, Henning P. Schmiedehausen wrote:
...
> Cisco: If I buy a _new_ PIIX oder LDIR today, do I get an ECN capable
> IOS or not? If not, will my CCNA know about this and upgrade my Box
> before deploying?
That cisco box is called PIX -- PIIX sounds like
[EMAIL PROTECTED] (Tony Hoyle) writes:
> These ISPs will *not* change simply because 1% of Linux users
> complain at them. They have been contacted about this and they know
> of the problem. I doubt they care.
Trust me, they care. Every Admin cares. They have, however, to convice
their
[EMAIL PROTECTED] (Chris Ricker) writes:
>> If ECN is so wonderful, why doesn't anybody actually WANT to use it
>> anyway?
>Lots of people do. Lots of other people (such as, in this case, hotmail)
>will never upgrade their software until the groundswell of complaints is
>more expensive than
"Adam J. Richter" <[EMAIL PROTECTED]> writes:
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled, would be
> > acceptable.
>
> Using a different source port number, even.
> As David pointed out, it is "reserved for future use - you must set
> these bits to zero and not use it _for your own purposes_. For non-rfc
> use of these bits _will_ break something the day we start using them
> for something useful.
>
> So, no reason for a firewall author to check these
"Adam J. Richter" wrote:
>
> I am surprised that anyone is seriously considering denying
> service to sites that do not implement an _experimental_ facility
> and have firewalls that try to play things safe by dropping packets
> which have 1's in bit positions that in the RFC "must be
I am surprised that anyone is seriously considering denying
service to sites that do not implement an _experimental_ facility
and have firewalls that try to play things safe by dropping packets
which have 1's in bit positions that in the RFC "must be zero."
If Microsoft were to
At Fri, 26 Jan 2001 15:08:21 + (GMT),
James Sutherland <[EMAIL PROTECTED]> wrote:
>
> On Fri, 26 Jan 2001, David S. Miller wrote:
> > James Sutherland writes:
> > > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > > RST packet as "go away and never ever send
In article <[EMAIL PROTECTED]>,
Randal, Phil <[EMAIL PROTECTED]> wrote:
>Because if we do try to force it, the response which will come
>back won't be "Linux is wonderful, it conforms to the standards".
>It will be "Linux sucks, we can't connect to xyz.com with it (or
>we can't connect because to
Lars Marowsky-Bree wrote:
>
> So you also turn of PMTU and just set the MTU to 200 bytes because broken
> firewalls may drop ICMP ?
That doesn't affect huge numbers of websites.
In the UK two of the largest ISPs - BT Internet and Freeserve - have
ECN-blocking
firewalls. So does
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T16:04:03,
>"Randal, Phil" <[EMAIL PROTECTED]> said:
>
> > We may be right, "they" may be wrong, but in the real world
> > arrogance rarely wins anyone friends.
>
> So you also turn of PMTU and just set the MTU to 200 bytes
On 2001-01-26T16:04:03,
"Randal, Phil" <[EMAIL PROTECTED]> said:
> We may be right, "they" may be wrong, but in the real world
> arrogance rarely wins anyone friends.
So you also turn of PMTU and just set the MTU to 200 bytes because broken
firewalls may drop ICMP ?
Sincerely,
Lars
Jamie Lokier wrote:
>
> Lars Marowsky-Bree wrote:
> > First, you are ignoring a TCP_RST, which means "stop trying".
>
> That's why we stop when we receive the second TCP RST.
> It's just like dropping due to congestion, which is of course perfectly
> safe in moderation.
>
No, you can't issue
James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do
> a Microsoft and force ECN on everyone, whether they like it
> or not. If ECN is so wonderful, why doesn't anybody actually
> WANT to use it anyway?
And there's the rub. Whether ECN is wonderful or not,
On Fri, 26 Jan 2001, James Sutherland wrote:
> Except you can't retry without ECN, because DaveM wants to do a Microsoft
> and force ECN on everyone, whether they like it or not.
Don't be absurd. It's a compile-time option that nobody, not even Dave
Miller, is forcing you to compile into your
Lars Marowsky-Bree wrote:
> If connect() suddenly did two connection attempts instead of one, just how
> many timeouts might that break?
Timeouts are already broken by applications that repeatedly call
connect(). You'd get better timeout behaviour by letting the kernel
enforce backoff.
> >
Dominik Kubla wrote:
>
> > Applications tend not to. Do we care about those that do?
>
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...
They dont connect but listen on these specified ports.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Fri, 26 Jan 2001, Lars Marowsky-Bree wrote:
> On 2001-01-26T15:08:21,
>James Sutherland <[EMAIL PROTECTED]> said:
>
> > Obviously. The connection is now dead. However, trying to make a new
> > connection with different settings is perfectly reasonable.
>
> No.
>
> If connect() suddenly
Dominik Kubla wrote:
> On Fri, Jan 26, 2001 at 04:03:42PM +0100, Jamie Lokier wrote:
> ...
> > Applications tend not to. Do we care about those that do?
>
> Apache? ... Sendmail? ... Samba? ... The class? ... Bueller? Bueller? ...
Yeah, Apache and Samba establish _outgoing_ connections with
David S. Miller wrote:
> > Does ECN provide perceived benefits to the node using it?
>
> Yes, endpoints and intermediate routers can tell the TCP sender about
> congestion instead of TCP having to guess about it based upon observed
> packet drop.
>
> It is a major enhancement to performance
Jamie Lokier writes:
> Does ECN provide perceived benefits to the node using it?
Yes, endpoints and intermediate routers can tell the TCP sender about
congestion instead of TCP having to guess about it based upon observed
packet drop.
It is a major enhancement to performance over any WAN.
On 2001-01-26T15:08:21,
James Sutherland <[EMAIL PROTECTED]> said:
> Obviously. The connection is now dead. However, trying to make a new
> connection with different settings is perfectly reasonable.
No.
If connect() suddenly did two connection attempts instead of one, just how
many
On Fri, 26 Jan 2001, David S. Miller wrote:
> James Sutherland writes:
> > I was not suggesting ignoring these. OTOH, there is no reason to treat an
> > RST packet as "go away and never ever send traffic to this host again" -
> > i.e. trying another TCP connection, this time with ECN disabled,
Lars Marowsky-Bree wrote:
> First, you are ignoring a TCP_RST, which means "stop trying".
That's why we stop when we receive the second TCP RST.
It's just like dropping due to congestion, which is of course perfectly
safe in moderation.
> You would have to retry a connection with a new source
David S. Miller wrote:
> People must fix their firewalls, there is no other way to
> fix the problem and get ECN properly deployed. I'm ceasing
> conversation on this thread from this point forward.
I suggest the ISPs fix their firewalls to strip ECN coming from their
Linux clients, providing a
Lars Marowsky-Bree writes:
> That would mean that the people worried about this should write a
> wrapper-library for the connect() call, and maybe add a no_ecn flag to a
> socket, and leave the kernel alone.
I'm not adding a no_ecn option for sockets. See my response
to Matti Aarnio earlier
On 2001-01-26T06:39:36,
"David S. Miller" <[EMAIL PROTECTED]> said:
> The RST frame does not indicate why it happened, so you may not intuit
> the reason, "retry" the connection, or anything else like that. It
> means connection failed, and we must return error from connect().
>
> Nothing
On 2001-01-26T13:44:53,
James Sutherland <[EMAIL PROTECTED]> said:
> > > A delayed retry without ECN might be a good compromise...
> > _NO!_
> Why? As it stands, I have ECN disabled. It's staying disabled until I know
> it won't degrade my Net access.
First, you are ignoring a TCP_RST,
Jamie Lokier writes:
> Ignore only _one_ RST frame (the first one)
Hmmm... let me say it for the hundreth time.
Valid RST frames cannot be ignored under any circumstances.
It is a full failure, period.
The RST frame does not indicate why it happened, so you may not intuit
the reason, "retry"
David S. Miller wrote:
> The connection failed, RST means connection reset. RST means all
> state is corrupt and this connection must die. It cannot be
> interpreted in any other way.
Therefore build a new connection, using a new source port if necessary.
-- Jamie
-
To unsubscribe from this
David S. Miller wrote:
> > Every single connection to ECN-broken sites would work as normal - it
> > would just take an extra few seconds. Instead of "Hotmail doesn't
> > work!" it becomes "Hrm... Hotmail is fscking slow, but Yahoo is fine. I'll
> > use Yahoo". A few million of those, and
"Jeremy M. Dolan" <[EMAIL PROTECTED]> writes:
> RFC1812 Requirements for IP Version 4 Routers
RFC 1812 mandates routing of IP packets with reserved flags, but not
for TCP packets.
> RFC2979 Behavior of and Requirements for Internet Firewalls
>
> The last one seems
James Sutherland wrote:
> I was not suggesting ignoring these. OTOH, there is no reason to treat an
> RST packet as "go away and never ever send traffic to this host again" -
> i.e. trying another TCP connection, this time with ECN disabled, would be
> acceptable.
Using a different source port
James Sutherland writes:
> I was not suggesting ignoring these. OTOH, there is no reason to treat an
> RST packet as "go away and never ever send traffic to this host again" -
> i.e. trying another TCP connection, this time with ECN disabled, would be
> acceptable.
The connection failed,
1 - 100 of 191 matches
Mail list logo
