Date: Sun, 17 Nov 2002 17:29:53 -0800 From: Terry Lambert <tlambert2@mindspring.com> To: soheil soheil <soheil_hh@hotmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Qs about snoop TCP Message-ID: <3DD84291.8041C327@mindspring.com> References: <F170DCY6Ag7jy7yxqsD0001530f@hotmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
soheil soheil wrote: > Dear All > > I want to know what is Snoop TCP , and Is it implemented on FreeBSD or Not ? Snoop TCP is a mechansim for performing impedence matching between a network with very little loss attached at the border of a network with much more loss. It operates as a pseudo-application proxy, and (effecitvely) implements retransmit queue caching at the border of the lossy network, so that retransmission requests do not go all the way back across the network. Think of it as a receive queue caching border router. If you had a wireless computer which connected through a "Snoop TCP" base station to Yahoo (for example), and you were downloading content from Yahoo, and the wireless link was espcially lossy, then your client would lose packets from the Yahoo server. When this happened, it would hit its timeout and ACK the previous packet all the way back to Yahoo, forcing the Yahoo server to retransmit its content all the way across the reliable link between the Yahoo server and the base station. The purpose of "Snoop TCP" is to prevent this. Once data has made it to the base station, the packets are cached. Effectively, the base station becomes a TCP transmit queue proxy cache for all TCP packets, rather than doing simple IP forwarding, and when the retransmit request comes, it serves the request locally. It also ACKs the data to the sender, when it arrives at the base station. Basically, this means that it *must* be possible for the wireless client to accept the packets that the server sent, and that the ACK must not provide information to the server which would have changed the content, length, or other attributes of the packet to more suit the client (once the base station accepts the packet on behalf of the client, the server discards it, and it can not be recovered). In general, this also requires a modification of the client to shorten the 2MSL timer, and on the client side of the base station, to shorten the 2MSL timer; this assumes a local link, and is potentially a bad thing to do, since the 2MSL timer is intended to deal with link latency, and the wired side of the base station is likely to be at least 10 times the data rate of the wireless side, if not 100 times (Gigabit <-> 11Mbit). In addition, the base station will suppress duplicate ACKs from the wireless client to Yahoo (this is a side effect), since it can service them from locally cached packet data. A consequence of the base station ACKing packets not yet ACKed by the wireless client is that it is then impossible to perform a cell hand-off between base stations, without complicated state replication protocols: the data, once ACK'ed, exists only in the transmit cache in the base station. If the wireless link timer is short enough *on BOTH the base station and the wireless client side*, then the base station should delay acknowledging packets to the Yahoo server; in fact, this is generally not the case, and the base station must treat the link as asymmetric, and eat the inability to hand-off. This is because in most cases, there is insufficient control of the client 2MSL timer to make the implementation practical (the 2MSL timer value is not a negotiated parameter between the base station and the mobile client computer, at the time the wireless link is established, which is what would be necessary). Another not-so-obvious consequence of this is that the number of connections is significantly limited. Specifically, you may have to handle the retransmit for two fill negotiated bidirectional window sizes worth of data per TCP connection per client, so the number of clients you could expect to handle with a "Snoop TCP" base station is significantly smaller than the number of clients you could handle otherwise, because the RAM requirements can be up to 64k per TCP connection. So the primary value in this is for base station firmware implementations for 802.11[ab] networks, and for proxy gateways, which already have application layer proxy caches, for telephone carriers. I rather expect that if you were AT&T Cable Internet, and were selling off your Cable Internet business at the first of the year (as AT&T is trying to do, which is why it's running the specials it has been running for the last three months, which all cut off at the first of the year: to push it's full cost subscriber base up to raise the selling price of the business unit), then you would be very interested in a cable-modem with a built-in wireless that permitted you, by virtue of being in your box, to limit the number of simultaneous clients, enforce security on to keep people from "wardriving", and to provide "Snoop TCP" to take retransmission load off your cable plant infrastructure. Currently, FreeBSD does not implement "Snoop TCP" or anything similar. It's actually pretty trivial to implement, if you need to do it; I rather expect that it would take about a month of work, given my experience with something similar taking about the same amount of time. It's unlikely, unless you intended to use FreeBSD as the firmware for your base stations, that adding "Snoop TCP" to FreeBSD would be a worthwhile project. Base station support in FreeBSD is limited to licensed base station hardware drivers for two cards, at this time. > After I want to know if There is any Performance Enhancing Proxy on the NET There are tons of them. You would need to be more specific for the performance of the situation, as it stands, and the specific situation itself, for someone to be able to pick a proxy. With no other information available about your application, I'd say the odds are 30% that you want "SQUID", from /usr/ports/www. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DD84291.8041C327>