Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism:

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism:

[Alan Cox]

> Our patch can be used along with SYN policing to prioritize incoming
> connection requests on a socket. SYN policing can be used to limit 
> the rate of a particular class, but it cannot be used to prioritize a 

No. Because you cant prove the packets are not spoofed. An attacker 
becomes able to block classes

[Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[Douglas M Freimuth]

On Fri, 27 Jul 2001,Sridhar wrote:

>The documentation on HOWTO use this patch and the test results which show
an
>improvement in connection rate for higher priority classes can be found at
our
>project website.
>        http://oss.software.ibm.com/qos

     For additional detail regarding the Prioritized Accept Queue (PAQ)
patch please read
"Kernel Mechanisms for Service Differentiation in Overloaded Web Servers"
originally published in
the 2001 Proceedings of the USENIX Annual Technical Conference
(USENIX Association, 2001), pp. 189-202. at the following USENIX site:

http://www.usenix.org/publications/library/proceedings/usenix01/voigt.html

For USENIX  nonmembers later this week will "reprint" this USENIX paper on
our project
website.
     http://oss.software.ibm.com/qos

--Doug
=================================================================
Doug Freimuth
   IBM TJ Watson Research Center
   Office  914-784-6221
   dmfreim@us.ibm.com

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[jamal]

For startes, can you fix
oss.software.ibm.com so it respects ECN?

In regards to policing SYNs i am not sure what additional
value you provide to the mechanisms currently available under
2.4 ingress traffic policing; the simplest example we provided
was on SYN policing albeit for DoS prevention.
Since i refuse to turn off ECN, i cant access your web page
You can use the skbmark to prioritize based on policies
installed on the ingress and drop early ...

Incase you are using this scheme already you should stick to the
ingress policer which uses a dual Token Bucket not what netfilter uses..

cheers,
jamal

On Mon, 30 Jul 2001, Douglas M Freimuth wrote:

>
>
> On Fri, 27 Jul 2001,Sridhar wrote:
>
> >The documentation on HOWTO use this patch and the test results which show
> an
> >improvement in connection rate for higher priority classes can be found at
> our
> >project website.
> >        http://oss.software.ibm.com/qos
>
>      For additional detail regarding the Prioritized Accept Queue (PAQ)
> patch please read
> "Kernel Mechanisms for Service Differentiation in Overloaded Web Servers"
> originally published in
> the 2001 Proceedings of the USENIX Annual Technical Conference
> (USENIX Association, 2001), pp. 189-202. at the following USENIX site:
>
> http://www.usenix.org/publications/library/proceedings/usenix01/voigt.html
>
> For USENIX  nonmembers later this week will "reprint" this USENIX paper on
> our project
> website.
>      http://oss.software.ibm.com/qos
>
> --Doug
> =================================================================
> Doug Freimuth
>    IBM TJ Watson Research Center
>    Office  914-784-6221
>    dmfreim@us.ibm.com
>
>
> _______________________________________________
> Diffserv-general mailing list
> Diffserv-general@lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/diffserv-general
>

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[Sridhar Samudrala]

Our patch can be used along with SYN policing to prioritize incoming
connection requests on a socket. SYN policing can be used to limit 
the rate of a particular class, but it cannot be used to prioritize a 
set of classes.  Priorized Accept Queues(PAQ) provides a way to classify 
incoming connections on a socket into a set of upto 8 classes and uses 
the priority of a connection to insert them into the accept queue. By 
default a connection is added at the end of the accept queue.  With PAQ, 
the connection is inserted at the end of the corresponding class within 
the accept queue. This will improve the latency and throughput for higher
priority connections.

We found that there are 2 ways to do SYN policing in linux. The first 
method is using the ingress policer which may be more effective as it 
uses dual token bucket.  The second way is to use iptables. It is simpler 
to configure via iptables as the rate limit can be specified in 
connections/sec as opposed to bytes/sec with ingress.  This may not be 
much of an issue if all the SYN packets are of fixed size (can change with 
options). 

Our patch does not in any way replace the functionality provided with 
SYN policing. It tries to extend the inbound qos functionality by adding 
prioritization of incoming connections that are going to be accepted.

oss.software.ibm.com is running linux 2.2.19. I guess linux should by
default ignore ECN bits if it is not enabled. Do you think this ECN problem 
has something to do with the server or some router on the way the server?
 
Thanks
Sridhar

On Mon, 30 Jul 2001, jamal wrote:
> 
> 
> For startes, can you fix
> oss.software.ibm.com so it respects ECN?
> 
> In regards to policing SYNs i am not sure what additional
> value you provide to the mechanisms currently available under
> 2.4 ingress traffic policing; the simplest example we provided
> was on SYN policing albeit for DoS prevention.
> Since i refuse to turn off ECN, i cant access your web page
> You can use the skbmark to prioritize based on policies
> installed on the ingress and drop early ...
> 
> Incase you are using this scheme already you should stick to the
> ingress policer which uses a dual Token Bucket not what netfilter uses..
> 
> cheers,
> jamal
> 
> On Mon, 30 Jul 2001, Douglas M Freimuth wrote:
> 
> >
> >
> > On Fri, 27 Jul 2001,Sridhar wrote:
> >
> > >The documentation on HOWTO use this patch and the test results which show
> > an
> > >improvement in connection rate for higher priority classes can be found at
> > our
> > >project website.
> > >        http://oss.software.ibm.com/qos
> >
> >      For additional detail regarding the Prioritized Accept Queue (PAQ)
> > patch please read
> > "Kernel Mechanisms for Service Differentiation in Overloaded Web Servers"
> > originally published in
> > the 2001 Proceedings of the USENIX Annual Technical Conference
> > (USENIX Association, 2001), pp. 189-202. at the following USENIX site:
> >
> > http://www.usenix.org/publications/library/proceedings/usenix01/voigt.html
> >
> > For USENIX  nonmembers later this week will "reprint" this USENIX paper on
> > our project
> > website.
> >      http://oss.software.ibm.com/qos
> >
> > --Doug
> > =================================================================
> > Doug Freimuth
> >    IBM TJ Watson Research Center
> >    Office  914-784-6221
> >    dmfreim@us.ibm.com
> >
> >
> > _______________________________________________
> > Diffserv-general mailing list
> > Diffserv-general@lists.sourceforge.net
> > http://lists.sourceforge.net/lists/listinfo/diffserv-general
> >
> 

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[Justin Guyett]

On Mon, 30 Jul 2001, Sridhar Samudrala wrote:

> oss.software.ibm.com is running linux 2.2.19. I guess linux should by
> default ignore ECN bits if it is not enabled. Do you think this ECN problem
> has something to do with the server or some router on the way the server?

ibm's [lotus's] firewall is blocking packets with ecn bits turned on.
http://gtf.org/garzik/ecn/


justin

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[David S. Miller]

Sridhar Samudrala writes:
 > oss.software.ibm.com is running linux 2.2.19. I guess linux should by
 > default ignore ECN bits if it is not enabled. Do you think this ECN problem 
 > has something to do with the server or some router on the way the server?

As Jamal and Jeff have mentioned, it's not a Linux problem.  Rather
it's the buggy firewall products IBM is using.

Later,
David S. Miller
davem@redhat.com

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism: Prioritized Accept Queue

[Chris Wedgwood]

On Mon, Jul 30, 2001 at 03:28:22PM -0700, Justin Guyett wrote:

    ibm's [lotus's] firewall is blocking packets with ecn bits turned on.
    http://gtf.org/garzik/ecn/

Lotus? Elsewhere IBM are using Cisco PIX, I assume this evil beast is
one too.



  --cw

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism:

[Sridhar Samudrala]

On Sun, 29 Jul 2001, Alan Cox wrote:

> > Our patch can be used along with SYN policing to prioritize incoming
> > connection requests on a socket. SYN policing can be used to limit 
> > the rate of a particular class, but it cannot be used to prioritize a 
> 
> No. Because you cant prove the packets are not spoofed. An attacker 
> becomes able to block classes

The aim of our patch is not to protect against a denial of service kind of
attack. It is more targeted towards a server that is getting overloaded
with valid connection requests. In such a scenario, this mechanism will 
provide better latency and connection rate for higher priority connections.

Thanks
Sridhar

Re: [Linux Diffserv] Re: [PATCH] Inbound Connection Control mechanism:

[kuznet]

Hello!

> > Our patch can be used along with SYN policing to prioritize incoming
> > connection requests on a socket. SYN policing can be used to limit 
> > the rate of a particular class, but it cannot be used to prioritize a 
> 
> No. Because you cant prove the packets are not spoofed. An attacker 
> becomes able to block classes

Their idea is feedback from prioritized accept queue to syn-table.
SYN floods just have no effect on this algoruthm.

They do really clever thing. Look at the case with single queue:
when apache is overloaded, accept queue grows. After some point
it becomes meaningless to queue new SYNs, they will only clog
syn-table, but we will not able to accept them in time.
>From the other hand, we cannot just drop SYNs after accept queue overflows,
because we will not have any connection ready, when apache overcomes
its troubles. I have thought on this, but without big success.
Typical accept latency is local and low, and typical syn-table latency
is rtt. The processes of establishing and accepting work at different
time scales and it is not quite trivial to get some useful smooth feedback
from high frequency accept queue to low frequency syn-table.
It is exactly the place where RED-like schemes should work well, by the way,
but I did not try this unfortunately. Trying instead to get feedback from
rate of SYNs, which was deemed to fail.

Actually, 2.4 does some trick of this kind in the most primitive form.

If their approach is really working, it can be extremally useful.

Alexey