Re: [Linux-l7sw-devel] New Layer7 switching project

[Willy T. <w...@1w...>]

On Thu, Dec 14, 2006 at 10:32:32PM +0100, Alexandre Cassen wrote:
> Hi Willy,
> 
> >Alex, if I may suggest, you should not lose too much of your time on exotic
> >features for a proof of concept. Your time seems more valuable to me on 
> >hard
> >to solve problems such as MSS and window scaling where fewer people can 
> >work
> >than regex. Better add a wishlist to the project with difficulty levels ;-)
> 
> yes you're right :) just want to extend userland soon since I spent
> already most of time in kernelspace.

I fairly can understand, sometimes I need to leave kernel for haproxy and
vice-versa :-)

> I already 'solved' the MSS
> problem with the current code setting server user_mss to client
> mss_clamp negociated => this is partial since in the other direction
> fragmentation can appear, need to deal with this, but most of
> datastream is from server to client so this assumption 'work' in most
> of HTTP workflow but to be rigurous must add fragmentation support :)

Hmmm be very careful with those assumptions. On a large scale infrastructure,
we encountered two problems with MSS :

  - ADSL users with broken PPPoE who cannot send large packets between their
    PC/router and their modem, and whose PC/router does not fragment nor
    clamp the MSS. They can do everything _except_ a few requests involving
    large POST requests. We had to perform this on netfilter just as a
    workaround for them since they were really many.

  - users on Token ring or FDDI announcing MSS values of 3960 and 4460, making
    it impossible to use Solaris 10's workaround consisting in announcing the
    same MSS as the client - 8 for the problem above.

  - fragments not being correctly supported by several network equipments such
    as a well known hardware-based load balancers and a well known firewall
    editor.

This leaves you with very few reliable options :

  - announcing 536 bytes to both client and server. This is dirty, but RFC791
    requires that any IP stack supports at least an MTU of 576 bytes, which
    means 536 bytes MSS in the default case (20 IP + 20 TCP), which is also
    the default MSS value. Reserving some space under this value for IP options
    (at most 60 bytes) and TCP options, it _must_ work everywhere.

  - slice and concatenate segments. This is a difficult work, which either
    requires to memorize skbs (client MSS < server MSS) or to create more
    skbs (client MSS > server MSS), but would be optimally efficient.


> I need now to extend to support wscale and sack. Will focus on those
> points during next week end.

SACK will not be easy at all I guess... An easy workaround still consists in
de-activating it. :-/

Cheers,
Willy