Dan McDonald wrote:
> Is this a design review or a code review? If the former, you should have
> time to address this.
It is a work in progress request for comments.
> I don't know if you've all taken a look at the bottom bunch of functions in
> $SRC/common/inet/ip/spd.c, but we have the "Fragment Cache" that used to live
> in SunScreen. It's currently used for fragment caching and checking for
> IPsec Tunnel Mode packets, but Paul (and he's the fragcache wizard) and I
> have inspected the code and it wouldn't take TOO much to generalize it to
> solve your ILB problems.
I think what it does is to store all the fragments so that
the complete packet can be checked. This is one of the
different ways I mentioned in my reply which we have considered.
But we are not sure if storing the fragments is the most
appropriate way to handle fragments in a LB. In fact, many
commercial LBs don't do this for performance reason. And we
want the ILB's performance to be as close as possible to the IP
stack's native forwarding performance.
We've considered other ways. For example, we can have a fragment
mapping table. When the first (offset 0) comes in, create an
entry to store where it is forwarded. Then when subsequent
fragments arrive, just check the table to find out where to send
them. It should be really quick. But the obvious problem is
that if the first fragment does not come first, it does not
work. And if the first fragment does not contain the transport
header info, it also does not work. But I guess the latter issue
should not happen normally.
We opt to defer further investigation of this to later phases
as not handling this should not affect the vast majority of
apps requiring load balancing. We can deal with this later.
> I've Bcc:ed Paul in case he wants to dive deeper, but ILB could:
>
> * Split out the fragcache code into its own source file.
>
> * Instantiate a fragcache_t whereever you need it. (After I review
> the whole design doc, I may be able to tell you exactly where!)
>
> * Use the fragcache code to solve your IP fragment problems.
Actually, for the purpose of load balancing, I believe reusing
the above code is probably an overkill. The reason is that ILB
does not really need to inspect the packet beyond the transport
header (at least for the intended use of ILB at this point). So
one way to solve the issue of the fragment mapping table is to
store the fragments for a short period of time if there is no
mapping. Once the first fragment is received, we can then forward
the other fragments. The code does not need to do any order
or sanity checking (except may be obvious issue related to DoS)
on those fragments. The performance should still be quick.
We will investigate further after the first deliverable of the
project.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
[email protected]
