Hi!
> > > >with the TCP ECN_ECHO and CWR flags set, to indicate
> > > >ECN-capability, then the sender should send its second
> > > >SYN packet without these flags set. This is because
> > >
> > > Now that is nice. The end user perceived effect is that folks with faulty
Hi!
with the TCP ECN_ECHO and CWR flags set, to indicate
ECN-capability, then the sender should send its second
SYN packet without these flags set. This is because
Now that is nice. The end user perceived effect is that folks with faulty
firewalls have
From: Bernd Eckenfels <[EMAIL PROTECTED]>
Date:Tue, 07 Nov 2000 03:38:35 +0100
Because this will add a Fallback (non ECN) packet to every denied
target. I think this is bad policy at least. It might violate the
RFCs, too. Keep in mind, we cannot recognice a rejection due
In article <[EMAIL PROTECTED]> you wrote:
> I'm still not sure why it's been decided not to do fallback or how this
> whole situation is any different from path MTU discovery.
Because this will add a Fallback (non ECN) packet to every denied target. I
think this is bad policy at least. It might
On Mon, 06 Nov 2000, Andi Kleen wrote:
> On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
> > >with the TCP ECN_ECHO and CWR flags set, to indicate
> > >ECN-capability, then the sender should send its second
> > >SYN packet without these flags set. This is because
On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
[snip]
> Now that is nice. The end user perceived effect is that folks with faulty
> firewalls have horrible slow web sites with a 3 or 4 second wait for each
> page. The perfect incentive. If only someone could do the same to path mtu
>
On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
> >with the TCP ECN_ECHO and CWR flags set, to indicate
> >ECN-capability, then the sender should send its second
> >SYN packet without these flags set. This is because
>
> Now that is nice. The end user perceived
>with the TCP ECN_ECHO and CWR flags set, to indicate
>ECN-capability, then the sender should send its second
>SYN packet without these flags set. This is because
Now that is nice. The end user perceived effect is that folks with faulty
firewalls have horrible slow web
Oliver Xymoron wrote:
>
> I'm still not sure why it's been decided not to do fallback or how this
> whole situation is any different from path MTU discovery.
It has:
"Changes to make to the ECN RFC before it goes to proposed standard:
* If the TCP host receives no response to a SYN
From: Bernd Eckenfels [EMAIL PROTECTED]
Date:Tue, 07 Nov 2000 03:38:35 +0100
Because this will add a Fallback (non ECN) packet to every denied
target. I think this is bad policy at least. It might violate the
RFCs, too. Keep in mind, we cannot recognice a rejection due to
Oliver Xymoron wrote:
I'm still not sure why it's been decided not to do fallback or how this
whole situation is any different from path MTU discovery.
It has:
"Changes to make to the ECN RFC before it goes to proposed standard:
* If the TCP host receives no response to a SYN packet
with the TCP ECN_ECHO and CWR flags set, to indicate
ECN-capability, then the sender should send its second
SYN packet without these flags set. This is because
Now that is nice. The end user perceived effect is that folks with faulty
firewalls have horrible slow web
On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
with the TCP ECN_ECHO and CWR flags set, to indicate
ECN-capability, then the sender should send its second
SYN packet without these flags set. This is because
Now that is nice. The end user perceived effect
On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
[snip]
Now that is nice. The end user perceived effect is that folks with faulty
firewalls have horrible slow web sites with a 3 or 4 second wait for each
page. The perfect incentive. If only someone could do the same to path mtu
On Mon, 06 Nov 2000, Andi Kleen wrote:
On Mon, Nov 06, 2000 at 11:02:47AM +, Alan Cox wrote:
with the TCP ECN_ECHO and CWR flags set, to indicate
ECN-capability, then the sender should send its second
SYN packet without these flags set. This is because
Now
In article [EMAIL PROTECTED] you wrote:
I'm still not sure why it's been decided not to do fallback or how this
whole situation is any different from path MTU discovery.
Because this will add a Fallback (non ECN) packet to every denied target. I
think this is bad policy at least. It might
On Sun, 5 Nov 2000, Barry K. Nathan wrote:
> +CONFIG_INET_ECN
> + Explicit Congestion Notification (ECN) allows routers to notify
> + clients about network congestion, resulting in fewer dropped packets
> + and increased network performance. This option adds ECN support to the
> + Linux
From: "Barry K. Nathan" <[EMAIL PROTECTED]>
Date:Sun, 5 Nov 2000 22:15:20 -0800 (PST)
This patch is against test10pre7 but applies cleanly to test10
final as well.
This patch is fine, thanks a lot.
OH, btw, for all folks out there. If there ever is an instance where
I
As the dates below show, I've actually been sitting on this patch for about
a week, but I just now got a chance to post it. I haven't had time to
fully, absolutely, completely grok what ECN is, so it's possible that this
help text is incorrect. If so, I'd like to hear about it.
This patch is
As the dates below show, I've actually been sitting on this patch for about
a week, but I just now got a chance to post it. I haven't had time to
fully, absolutely, completely grok what ECN is, so it's possible that this
help text is incorrect. If so, I'd like to hear about it.
This patch is
On Sun, 5 Nov 2000, Barry K. Nathan wrote:
+CONFIG_INET_ECN
+ Explicit Congestion Notification (ECN) allows routers to notify
+ clients about network congestion, resulting in fewer dropped packets
+ and increased network performance. This option adds ECN support to the
+ Linux kernel,
21 matches
Mail list logo
