|
Hello,
On Mon, 18 Feb 2002, Roberto Nibali wrote:
> Hello Julian,
>
> Sorry for the delay, but days still only have 24 hours :(
>
> > Currently, all schedulers can receive weight and in most
> > cases this is enough. If you want to feed it with something else
> > then it should be implemented. WRR is clever enough to keep the
> > weights you set. From your words I assume it is not enough? As
>
> It is enough actually for now. But I need to export the byte and packet
> counter :) You smell it now?
They are already exported. But you have to teach the WLC
scheduler to which estimator to apply the weights: cps, inpps, outpps,
inbps, outbps. Currently, it is to actconns&inactconns but this is
something like cps. May be you can add additional scheduler, say
ip_vs_wlt.c (Weighted Least Traffic). The problem is that you
can monitor outbps only for NAT. Using inbps is useless for normal
web or ftp traffic. You need stats from the interfaces and dynamicly
to change the WRR's weghts. Without additional information about
the memory or CPU load in the real servers, this new scheduler
is going to send more traffic to the already overloaded real
servers. You need a complex expression, not only the traffic.
Of course, there will be setups where the estimated traffic is
enough.
> > for testing new scheduler, why not to copy one simple scheduler
> > and to fill all its hooks. Rename ip_vs_wrr.c to ip_vs_wrr_saved.c
> > and ip_vs_thebestone.c to ip_vs_wrr.c and do ipvsadm -A -s wrr :)))
>
> LOL, ip_vs_wrr will be so obsoleted, that I don't even care to copy it
> anymore :)
I'm not sure, WRR is very useful for user space control
that can provide a complex formula to set the weights dynamicly.
The actual traffic is only a small part from this expression. In
some of the cases the real servers can do CPU intensive job
which costs more than just to send packets.
> Well, why not make it like with ftp? As soon as we get CIP:500 ->
> VIP:500 we start a persistent entry and add ESP/AH to it, when we detect it?
I even decided not to create any ESP/AH entries, see the
document I started yesterday, I updated it today with some info
for NAT Traversal. I can start coding soon but the funny part is
that opportunism is not widely used, nor the NAT Traversal :)
> > Yep, we need to know when one connection dies.
>
> AFAIK a IPsec connection never dies or at least a router in between
> doesn't know that without inspecting the packets. Ok, you know when a
> connection dies, but this is only TCP state related. But an IPsec
> session could not have packets for an hour and still claim to be related
> to the old session with the same old SPI. This is the nasty point. We
> can solve this, when we can tell the director about the rekeying timeout
> by configuration.
Yes, for now, it seems a 2-state ISAKMP handling is enough.
Of course, we can base our timeouts only to the ISAKMP protocol.
> > Yes, with the persistent fwmark service we can forward
> > any protocol, the minimum we need to know is when to create and when
> > to release a LVS entry. Everything else is routing. We don't want
> > to rely on the dropentry memory-defense strategy to make the decision for
> > the entry life :)
>
> Why? We should know when a SPI gets updated. The session might still be
> valid for the dropentry but the SPI changed. Ok, the only problem we
> would have there is that we would generate yet more imbalance because an
> entry would stay persistent longer than it actually needed to.
I don't think we can connect one client to many real servers
because this breaks the ISAKMP protocol. IMO, we need to create
only ISAKMP entries, no ESP or AH entries are needed, their packets
will just hold a reference to the ISAKMP entry (if such exists)
while the packet is handled and even will not update the expiration
timer. Only the ISAKMP packets will update the expiration timer.
Implicit persistence with a slave ESP/AH traffic.
> > Yes, for our routing decisions ESP/AH is a IP protocol, we
> > even don't need to look at the protocol header and as a bonus we
> > even don't need to defragment these packets. Defrag is needed only
> > for TCP/UDP/ICMP because we use information from their headers.
> > So, ESP/AH is easy for forwarding but ISAKMP ... we still don't know.
>
> Isn't it just a stupid UDP? I hardly ever talks anyway.
Yes, but we can look in the [ir]cookies to know one
of the 2 possible states we can support.
> > Yes, run your new scheduler, apply dynamic weights and
> > the imbalance caused from persistence is gone :) Almost.
>
> To bring it to the point. We should have a scheduler that calculates the
> bytes and the packets and does weighting according to those values. This
> is for all brain damaged AC super-ecommerce implementations that need a
> persistency timeout of 7200s.
May be you are the one who should experiment with the
real server's estimators to tune WLC or a new scheduler :)
> > The persistence timeout is useless if we don't have correct
> > control for the ISAKMP and the ESP/AH entry life, they can't live
> > forever in our context. We should analyze ISAKMP (if someone is
> > aware please help) to add correct entry life timeouts because the
> > problem with attacks can be unavoidable. This is DR method (input
> > only).
>
> See, we have to inspect packets, at least UDP/VIP:500 ones. There you
> find the information about the SPI and the lifetime.
No, if the payload is encrypted we can't see anything.
Only the cookies, if I understand correctly the issue.
> Cheers,
> Roberto Nibali, ratz
Regards
--
Julian Anastasov <ja@xxxxxx>
|
