|
> It just seems like we'd be meddling in foreign waters. Let TCP do what we
> pay it to do and otherwise leave it alone.
Heh, and we're not meddling in foreign waters already? NAT/DR/TUN to
multiple nodes with the same IP address isn't screwy to begin with? We're
already in foreign waters, doing things that weren't intended. Why get
conservative about it now? :)
Besides, we're not interfering with how TCP works, we're just monitoring
things, and _maybe_ doing something about it.
The idea behind this is that if we see the same SYN sent multiple times,
we know that for some reason, the person attempting to create a connection
is never receiving a SYN-ACK -- or at least is claiming something to that
effect.
What could cause this?
1. Real server is never receiving the SYN, and/or is never sending a
SYN-ACK.
2. Client is never receiving a SYN-ACK because it's being lost in
transit.
3. Client is doing broken things -- either intentionally (syn flood) or
unintentionally (bugs)
I wouldn't mind knowing about it in any of these cases.
There's another possibility:
4. Server requested retransmission of SYN
When would that happen though? Checksum error? Any other cases?
The idea is to cut down on the time it takes for me to notice that there's
a problem, irrespective of where that problem may be. I think this could
do that. LVS isn't just being used for load-balancing, it's being used
for high availability, and the name of the game with high-availability is
detecting problems -- fast -- so you can solve or work around them. This
could be another tool to do that.
If it's a routing problem, I can route around it. If it's a downed
server, I can remove it from the pool. If it's a syn-flood, I can start
adding some firewall rules to stop the attack up stream. In any case, I
know that something is amiss, and I can do something about it.
Thanks,
Kyle Sparger - Senior System Administrator
Dialtone Internet - Extremely Fast Web Systems
(954) 581-0097 - Voice (954) 581-7629 - Fax
ksparger@xxxxxxxxxxxxxxxxxxxx
http://www.dialtoneinternet.net
On Thu, 10 Aug 2000, Ted Pavlic wrote:
> > I don't know if this applies to all operating systems, or if it's a
> > standard or what, but I noticed that when resending TCP packets with the
> > SYN bit set, the sequence number does not change. Now, with what I know
> > of TCP, this is exactly the desired behaviour -- can anyone enlighten us
> > if it's standardized or not? -- and we could use this to our advantage.
>
> There is a standardized three-way handshake and Positive Acknowledgement
> with Re-transmission (PAR) which is an integral part of TCP.
>
> Basically each byte of data from the initial sequence number is numbered
> sequentially. The host receiving data during a transaction sends an
> acknowldegement back to the sending host which includes the sequence number
> of the last byte of data which was successfully received. The sending host
> then resends data as necessary depending on what acknowledgement number was
> received.
>
> So the sequence numbers on retransmitted bytes may return to values they
> have been times before if the receiving host asks the sending host to resend
> data. This is just how TCP works. The sequence numbers are the only way that
> either host keeps all of its chickens in order, so when data is resent in
> order for both sides to know what's going on, the sequence numbers have to
> be rewound and played back.
>
> > It occured to me that if we were to keep track of not only SYNs, but their
> > sequence numbers, we could possibly very easily detect when a TCP based
> > real server is having problems by noticing that we've seen that sequence
> > number in a SYN from that host not too long ago, and either remove that
> > server from the pool, or (more likely) notify userspace for appropriate
> > handling.
>
> I really don't think there's a lot that can be done with this. PAR has been
> built into TCP to make it a reliable protocol. It helps gaurantee that all
> data actually gets from point A to point B. If retransmissions need to
> occur, it may have nothing to do with either end -- it may have to do with
> something way out on the Internet which cannot be changed. If there was
> anything we could do with this information, TCP would already be doing it;
> we'd just be reinventing the wheel.
>
> And what would keep someone from sending a bunch of ACKs back to our real
> servers... forcing them to retransmit... and then having us take them down.
> <?>
>
> Also, I think you're suggesting that we make observations at the network
> layer by using this information... however... if things make it all the way
> up the ladder to the protocol layer, the network is probably fine.
>
> It just seems like we'd be meddling in foreign waters. Let TCP do what we
> pay it to do and otherwise leave it alone.
>
> > Any thoughts?
>
> But those are just my opinions.
>
> All the best --
> Ted
>
>
|
