From: Ido Schimmel
[ Upstream commit 66167c310deb4ac1725f81004fb4b504676ad0bf ]
Cited commit changed the behavior of the software data path with regards
to the ECN marking of decapsulated packets. However, the commit did not
change other callers of __INET_ECN_decapsulate(), namely mlxsw. The
From: Ido Schimmel
[ Upstream commit 66167c310deb4ac1725f81004fb4b504676ad0bf ]
Cited commit changed the behavior of the software data path with regards
to the ECN marking of decapsulated packets. However, the commit did not
change other callers of __INET_ECN_decapsulate(), namely mlxsw. The
From: Hangbin Liu
[ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ]
The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01
should be inner ECT(0) + outer ECT(1). Based on the description of
__INET_ECN_decapsulate, the final decapsulate value should be
ECT(1). So fix
From: Hangbin Liu
[ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ]
The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01
should be inner ECT(0) + outer ECT(1). Based on the description of
__INET_ECN_decapsulate, the final decapsulate value should be
ECT(1). So fix
From: Hangbin Liu
[ Upstream commit 5aa3c334a449bab24519c4967f5ac2b3304c8dcf ]
The ECN bit defines ECT(1) = 1, ECT(0) = 2. So inner 0x02 + outer 0x01
should be inner ECT(0) + outer ECT(1). Based on the description of
__INET_ECN_decapsulate, the final decapsulate value should be
ECT(1). So fix
From: Guillaume Nault
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip
From: Guillaume Nault
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip
From: Guillaume Nault
commit 2e5a6266fbb11ae93c468dfecab169aca9c27b43 upstream.
RT_TOS() only masks one of the two ECN bits. Therefore rpfilter_mt()
treats Not-ECT or ECT(1) packets in a different way than those with
ECT(0) or CE.
Reproducer:
Create two netns, connected with a veth:
$ ip
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Guillaume Nault
[ Upstream commit 21fdca22eb7df2a1e194b8adb812ce370748b733 ]
RT_TOS() only clears one of the ECN bits. Therefore, when
fib_compute_spec_dst() resorts to a fib lookup, it can return
different results depending on the value of the second ECN bit.
For example, ECT(0) and ECT
From: Eric Dumazet
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since callers
pass a pointer that might be freed by pskb_may_pull()
From: Eric Dumazet
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since callers
pass a pointer that might be freed by pskb_may_pull()
From: Eric Dumazet
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since callers
pass a pointer that might be freed by pskb_may_pull()
On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote:
> On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman
> wrote:
> >
> > From: Eric Dumazet
> >
> > IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
> > IP header is already pulled.
> >
> > geneve does not ensure this yet.
> >
> > Fi
On Thu, Dec 10, 2020 at 03:53:09PM +0100, Eric Dumazet wrote:
> On Thu, Dec 10, 2020 at 3:40 PM Greg Kroah-Hartman
> wrote:
> >
> > On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote:
> > > > On Thu, Dec 10, 2020 a
On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote:
> > On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman
> > wrote:
> > >
> > > From: Eric Dumazet
> > >
> > > IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
>
On Thu, Dec 10, 2020 at 3:40 PM Greg Kroah-Hartman
wrote:
>
> On Thu, Dec 10, 2020 at 03:38:44PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Dec 10, 2020 at 03:32:12PM +0100, Eric Dumazet wrote:
> > > On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman
> > > wrote:
> > > >
> > > > From: Eric Duma
On Thu, Dec 10, 2020 at 3:26 PM Greg Kroah-Hartman
wrote:
>
> From: Eric Dumazet
>
> IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
> IP header is already pulled.
>
> geneve does not ensure this yet.
>
> Fixing this generically in IP_ECN_decapsulate() and
> IP6_ECN_decapsulate() is not pos
From: Eric Dumazet
[ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ]
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since c
From: Eric Dumazet
[ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ]
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since c
From: Eric Dumazet
[ Upstream commit 4179b00c04d18ea7013f68d578d80f3c9d13150a ]
IP_ECN_decapsulate() and IP6_ECN_decapsulate() assume
IP header is already pulled.
geneve does not ensure this yet.
Fixing this generically in IP_ECN_decapsulate() and
IP6_ECN_decapsulate() is not possible, since c
incoming segments with CE set
+0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535
+0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535
+0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535
// Stack repsonds with ECN ECHO
+0.0 >[noecn] . 1001:1001(0) ack 12001
+0.0 >[noecn] E. 1001:10
incoming segments with CE set
+0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535
+0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535
+0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535
// Stack repsonds with ECN ECHO
+0.0 >[noecn] . 1001:1001(0) ack 12001
+0.0 >[noecn] E. 1001:10
incoming segments with CE set
+0.1 <[ect0] . 11001:12001(1000) ack 1001 win 65535
+0.0 <[ce]. 12001:13001(1000) ack 1001 win 65535
+0.0 <[ect0] P. 13001:14001(1000) ack 1001 win 65535
// Stack repsonds with ECN ECHO
+0.0 >[noecn] . 1001:1001(0) ack 12001
+0.0 >[noecn] E. 1001:10
From: "Toke H�iland-J�rgensen"
[ Upstream commit eebabcb26ea1e3295704477c6cd4e772c96a9559 ]
WireGuard currently only propagates ECN markings on tunnel decap according
to the old RFC3168 specification. However, the spec has since been updated
in RFC6040 to recommend slightly
certain configuration, under congestion,
the HW emulates a switch doing ECN marking on packets using ECN
indication on the completion descriptor (CQE).
The driver needs to set the ECN bits on the packet SKB,
such that the network stack can react on that, this commit does that.
Needed by downstream
) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets
4.4-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets
) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd (&quo
) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd (&quo
4.9-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets
4.17-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets
) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd
4.14-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 522040ea5fdd1c33bbf75e1d7c7c0422b96a94ef ]
ECN signals currently forces TCP to enter quickack mode for
up to 16 (TCP_MAX_QUICKACKS) following incoming packets
) made us rethink
about our recent patch removing ~16 quick acks after ECN events.
tcp_enter_quickack_mode(sk, 1) makes sure one immediate ack is sent,
but in the case the sender cwnd was lowered to 1, we do not want
to have a delayed ack for the next packet we will receive.
Fixes: 522040ea5fdd
4.15-stable review patch. If anyone has any objections, please let me know.
--
From: Neal Cardwell
[ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ]
This patch enables tail loss probe in cwnd reduction (CWR) state
to detect potential losses. Prior to this patch, si
From: Neal Cardwell
[ Upstream commit b4f70c3d4ec32a2ff4c62e1e2da0da5f55fe12bd ]
This patch enables tail loss probe in cwnd reduction (CWR) state
to detect potential losses. Prior to this patch, since the sender
uses PRR to determine the cwnd in CWR state, the combination of
CWR+PRR plus tcp_tso
I'm trying to generate phantom ECN events to (manually) decrease the
transmission rate/throughput.
The signals is meant to be generated and received on a single host. I
don't want the ECN event to generate a CWR (Congestion Window Reduced)
response to the sender. I'm trying to t
I'm trying to generate phantom ECN events to (manually) decrease the
transmission rate/throughput.
The signals is meant to be generated and received on a single host. I
don't want the ECN event to generate a CWR (Congestion Window Reduced)
response to the sender. I'm trying to t
3.2.65-rc1 review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
commit bd14b1b2e29bd6812597f896dde06eaf7c6d2f24 upstream.
It appears some networks play bad games with the two bits reserved for
ECN. This can trigger false congestion
, though whether or not we
should reflect ECN bits may be up for debate.
Signed-off-by: Alex Gartrell
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/ipvs/ip_vs_xmit.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net
, though whether or not we
should reflect ECN bits may be up for debate.
Signed-off-by: Alex Gartrell
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/ipvs/ip_vs_xmit.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net
, though whether or not we
should reflect ECN bits may be up for debate.
Signed-off-by: Alex Gartrell
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman
---
net/netfilter/ipvs/ip_vs_xmit.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net
3.6-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 51ec04038c113a811b177baa85d293feff9ce995 ]
IPv4 side of the problem was addressed in commit a9e050f4e7f9d
(net: tcp: GRO should be ECN friendly)
This patch
On Thu, Jun 14, 2001 at 01:33:53PM +0200, Anders Peter Fugmann wrote:
> Great to hear, but I cannot find anything that backs it up.
> I really want to see the final RFC.
>
> Perhaps you could send me an URL pointing to it?
Usually takes a few days until the RFC editor will announce and
publish
Hi Jamal
Great to hear, but I cannot find anything that backs it up.
I really want to see the final RFC.
Perhaps you could send me an URL pointing to it?
TIA
Anders Fugmann
jamal wrote:
>
> The IESG approved ECN as a proposed standard on the 12th of June.
> That means as of no
The IESG approved ECN as a proposed standard on the 12th of June.
That means as of now, anyone blocking ECN bits is considered to be
blaspheming.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
Rogier Wolff wrote:
> The "we'll turn it on in February" warning is worth NOTHING in this
> situation: February comes and goes. March comes and goes. Everybody
> who read the warning will think: Ok, so I must be fine.
>
> A warning of the form: "ECN will g
Folks, herewith I declare this topic ("ECN is on") TABOO, if
you want to continue discussing it, do that at linux-kernel
WITH NEW TOPIC.
My original message had reply-to pointing to linux-kernel,
but all it takes is single person to ignore that...
Spare the other
Richard Gooch <[EMAIL PROTECTED]> writes:
> Sure, Dave is being bloody-minded, but that's the only way we'll see
> people get off their fat, lazy asses and fix their broken systems.
> In fact, hopefully he's still in a dark mood, and he may take up the
> suggestion to bounce mails of the followin
On Tue, May 22, 2001 at 11:55:59AM -0500, Joe Barr wrote:
> What is ECN? Is it the reason SNORT has started this lately:
http://vger.kernel.org/
Follow the links, and you will get an exellent answer.
>
> Active System Attack Alerts
> =-=-=-=-=-=-=-=-=-=-=-=-=-=
> May 2
FOLKS, I HAVE ALL THE TIME USED 'Reply-To:' HEADER POINTING
TO linux-kernel -- INSTEAD OF ALL THE LISTS...
If you want to continue this, do it there.
(Before I decide to taboo "Re: ECN is on!" subject line..)
On Tue, May 22, 2001 at 12:23:29PM -0400, Richard Goo
What is ECN? Is it the reason SNORT has started this lately:
Active System Attack Alerts
=-=-=-=-=-=-=-=-=-=-=-=-=-=
May 22 10:11:18 pooh snort: spp_portscan: PORTSCAN DETECTED from 199.183.24.194
(STEALTH)
May 22 10:11:22 pooh snort: spp_portscan: portscan status from 199.183.24.194: 1
PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: ECN is on!
Rogier Wolff wrote:
> The "we'll turn it on in February" warning is worth NOTHING in this
> situation: February comes and goes. March comes and goes. Everybody
> who read the warning will
Tony Hoyle writes:
> Richard Gooch wrote:
>
> > In fact, hopefully he's still in a dark mood, and he may take up the
> > suggestion to bounce mails of the following type:
> > - MIME encoded
> > - HTML encoded
> > - quoted printables (those stupid "=20" things are particuarly hard to
> > read).
Matti Aarnio writes:
> On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote:
> ...
> > Sure, Dave is being bloody-minded, but that's the only way we'll see
> > people get off their fat, lazy asses and fix their broken systems.
> > In fact, hopefully he's still in a dark mood, and he may t
#x27;s announcement, I updated the FAQ
> to reflect that we're now running ECN.
>
> People have had plenty of warning. Think of it as a bonus that it
> didn't happen back in February. They've had an extra 3 months to sort
> something out.
The "we'll turn it on in
On Tue, May 22, 2001 at 05:00:22PM +0100, Tony Hoyle wrote:
> > suggestion to bounce mails of the following type:
> > - MIME encoded
> > - HTML encoded
> > - quoted printables (those stupid "=20" things are particuarly hard to
> > read).
>
> Surely it'd be better to get the list to filter them
On Tue, May 22, 2001 at 09:06:25AM -0400, Richard Gooch wrote:
...
> Sure, Dave is being bloody-minded, but that's the only way we'll see
> people get off their fat, lazy asses and fix their broken systems.
> In fact, hopefully he's still in a dark mood, and he may take up the
> suggestion to boun
Richard Gooch wrote:
> In fact, hopefully he's still in a dark mood, and he may take up the
> suggestion to bounce mails of the following type:
> - MIME encoded
> - HTML encoded
> - quoted printables (those stupid "=20" things are particuarly hard to
> read).
Surely it'd be better to get the l
Brent D. Norris writes:
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fix their kit.
> >
> > We will remove these people, that's all.
>
> Isn't this a problem though because the messge saying that ECN was
> e
Alan Cox writes:
> > Matti Aarnio writes:
> > > I am contemplating to periodically turn off the ECN bit to
> > > let email out, but DaveM has veto there.
> >
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fi
Folks, don't speculate. You are late anyway.
We just had ECN off for two hours, and all sites which didn't
commit harakiri at their firewalls ("bad TCP frame from that address,
I will place that source into dead list") now either got their message,
or are h
ll be re-enabled on June 10th or something, and everyone must
>do thus and so or they will break on that day?
>
>Vague things like "it'll be turned on real soon now" or ASAP really mean
>"never" since admins always have things with real deadlines at the top
>of
"David S. Miller" wrote:
>
> Matti Aarnio writes:
> > I am contemplating to periodically turn off the ECN bit to
> > let email out, but DaveM has veto there.
>
> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix
On Tue, May 22, 2001 at 06:51:57AM -0500, Brent D. Norris wrote:
> > I veto, the whole point of moving to ECN was to make a statement and
> > get people to fix their kit.
> >
> Isn't this a problem though because the messge saying that ECN was enabled
> was set after
Matti Aarnio <[EMAIL PROTECTED]> writes:
> ... and immediately I have been able to verify a bunch of
> domains/servers which won't get thru when incoming connection
> has ECN.
As a matter of interest, are you also noting how many actually
negotiate ECN rather than simp
> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix their kit.
>
Isn't this a problem though because the messge saying that ECN was enabled
was set after ECN was enabled? Thus these people have no idea what is
going on and they probably won&
On Tue, May 22, 2001 at 01:10:31PM +0300, Matti Aarnio wrote:
> This list is NOT exhaustive of domains with problems, it
> primarily lists only those who are subscribers of linux-kernel,
> and thus accumulated (al lot) more than 1 email with "connection
> timed out" status into vger's queue.
>
>
> Matti Aarnio writes:
> > I am contemplating to periodically turn off the ECN bit to
> > let email out, but DaveM has veto there.
>
> I veto, the whole point of moving to ECN was to make a statement and
> get people to fix their kit.
>
> We will remove these p
Matti Aarnio writes:
> I am contemplating to periodically turn off the ECN bit to
> let email out, but DaveM has veto there.
I veto, the whole point of moving to ECN was to make a statement and
get people to fix their kit.
We will remove these people, that's all.
Later,
Davi
... and immediately I have been able to verify a bunch of
domains/servers which won't get thru when incoming connection
has ECN.I tested all of these with Linux running ECN, and
Solaris 2.6 without ECN. When Solaris got connection, and
ECN-Linux didn't, domain and its server
I simply crontab an ECN off period for five minutes every hour and flush
the mail queue.
David.
Holger Lubitz wrote:
>"H. Peter Anvin" wrote:
>
>>I suspect that the main way to get this thing fixed is to make sure
>>ECN is enabled on the server side; for example
> I suspect that the main way to get this thing fixed is to make sure
> ECN is enabled on the server side; for example, we have turned on ECN
> on kernel.org. If a user is using a broken software stack, it's their
> loss, not ours.
I agree it's the server side that w
"H. Peter Anvin" wrote:
> I suspect that the main way to get this thing fixed is to make sure
> ECN is enabled on the server side; for example, we have turned on ECN
> on kernel.org. If a user is using a broken software stack, it's their
> loss, not ours.
This is wha
the reference to zyxel (from Jeff G ?) :
>ZyXEL P681 -> firmware v2.50(T.05)b6 | 03/28/2001)
btw: it is already offically release version 2.50(T.05)| 04/13/2001
and the ECN issue is fixed.
I have asked if the developers would ake actoin on the other
routers/firewalls as well to f
On Wed, 9 May 2001, Gregory Maxwell wrote:
> On Wed, May 09, 2001 at 01:08:31PM -0400, God wrote:
> > On Wed, 9 May 2001, Gregory Maxwell wrote:
> >
> > > 2) They certainly are. Every once in a while they go through a period of
> > >silently dropping all email coming from hosts that don't h
On Wed, May 09, 2001 at 01:08:31PM -0400, God wrote:
> On Wed, 9 May 2001, Gregory Maxwell wrote:
>
> > 2) They certainly are. Every once in a while they go through a period of
> >silently dropping all email coming from hosts that don't have PTRs.
> >This would be no worse.
>
> ACK
Followup to: <[EMAIL PROTECTED]>
By author:God <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Agreed. For now ECN has been disabled here. I got tired of so many sites
> not supporting it that I gave up. Maybe by 2.8.x kernels it will be worth
> turning ba
On Wed, 9 May 2001, Gregory Maxwell wrote:
> 2) They certainly are. Every once in a while they go through a period of
>silently dropping all email coming from hosts that don't have PTRs.
>This would be no worse.
ACK Which do you mean? :
-Hosts that don't have valid PTRs (which wou
[snip]
> >
> >
> > I tried to get my local bank to fix their internet banking service about a
> > month ago. I ran into a 'brick wall'. They only support Windows and MacOS,
> > since neither currently implement ECN, they don't have a problem :-(
On Wed, May 09, 2001 at 10:10:29AM -0400, Horst von Brand wrote:
> Gregory Maxwell <[EMAIL PROTECTED]> said:
>
> [...]
>
> > Anyone have any friends at AOL? I wonder what the effect on these
> > non-conformant sites would be if AOL's proxy's became ECN en
Gregory Maxwell <[EMAIL PROTECTED]> said:
[...]
> Anyone have any friends at AOL? I wonder what the effect on these
> non-conformant sites would be if AOL's proxy's became ECN enabled?
And AOL is sure crazy enough to "break compatibility with everybody" just
out
On Tue, May 08, 2001 at 10:31:23PM -0400, jamal wrote:
> Folks,
>
> ECN is about to become a Proposed Standard RFC. Thanks to
> efforts from the Linux community, a few issues were discovered
> in the course of deploying the code. Special kudos go to Alexey
> Kuznetsov and D
only support Windows and MacOS,
> since neither currently implement ECN, they don't have a problem :-(
>
> The only answer I got is 'we don't support Linux'. The operator tried
> to find some one interested in the network, but the answer was always
> the same.
olitely using a standard
> email ask them that their site was non-conformant.
I tried to get my local bank to fix their internet banking service about a
month ago. I ran into a 'brick wall'. They only support Windows and MacOS,
since neither currently implement ECN, they don
> This was the big argument I was running into from sites, "well it
> isn't standard yet, when it is we'll do something about it". The
> larger sites like to avoid updates until absolutely necessary.
Good grief - nothing like planning ahead ... and these large-site
administrators actually acc
On Tue, 8 May 2001, jamal wrote:
> Any one wishing to volunteer, please still send your emails in --
> we should be ready in a few days from now,
>
I guess i should have mentioned the IESG is sitting in to approve ECN
as proposed standard in about a week or so.
cheers,
jamal
-
To un
On Tue, 8 May 2001, David S. Miller wrote:
>
> I believe it would only be prudent to actually send out these messages
> starting at the moment ECN is officially standard.
>
> This was the big argument I was running into from sites, "well it
> isn't standard yet, w
jamal writes:
> Help is needed to contact these site owners and politely using a standard
> email ask them that their site was non-conformant.
> Point them to Sally's draft and the fact that ECN is becoming standard
> in the next week or so. Also to Jeff's ECN-
Folks,
ECN is about to become a Proposed Standard RFC. Thanks to
efforts from the Linux community, a few issues were discovered
in the course of deploying the code. Special kudos go to Alexey
Kuznetsov and David Miller.
I wont go into details of the issues other than to say some
midlle-box
little typo:
>From 5. External resources (notice "Congrestion"):
Sally Floyd's page on Explicit Congrestion Notification in TCP/IP.
http://www.aciri.org/floyd/ecn.html
--
Drew Bertola | Send a text message to my pager or cell ...
| http://jpager.com/Drew
-
To unsubscribe
To all--
As ECN deployment increases, people are increasingly noticing that some
key web sites are still inaccessible when ECN is enabled.
A Web site has been created to assist with this transition, with two key
features: (1) ECN-related fixes are posted on this Web page, and (2)
vendors whose
Hi
no they should not be effected
the place that starts the connection eg send the first SYN
has to ask to use ECN if it is not requested it will
never be used in that connection
In local.linux-kernel-list, you wrote:
>Hello,
>
>What is the impact of enabling ECN on the server side
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Con: people behind broken firewalls can't connect.
Are you sure that is correct? "Servers" normally listen for incoming
connections from clients rather than establish them[1]. So, if the
server implements ECN the
1 - 100 of 385 matches
Mail list logo
