On Friday 19 August 2005 12:37 am, Wael Noureddine wrote: > > The is no RFC violated by being "bursty". Show me the RFC where TCP > > burstiness is "standardized". This is yet another strawman. > > You surely know this is a recurring theme in all congestion control RFCs > (RFC2581 in particular), > as well as in the "Known TCP Implementation Problems" RFC2525.
TSO increases micro-burstiness. Clearly macro-burstiness has konwn harmful effects, but I know of nothing in the literature showing harmful effects of small bursts. I'm genuinely curious to see any papers on this subject if you have pointers to them. Admittedly the distinction here between micro and macro is fuzzy, but I'd define "micro" as a small fraction of the cwnd. The Linux TSO implementation doesn't necessarily do the *best* thing, but some work has gone in to this recently, and I think it does reasonably well at this point under most conditions. Addressing macro-burstiness issues is entirely separate from TSO and is a topic of ongoing research. One case that does concern me with TSO is switches with short queues. Imagine a GigE switch with a 64k buffer. If you have two or three machines doing TSO toward the same switch port, they're going to start trampling all over each other. However, I'd say this is too short a queue anyway for GigE -- short enough that you're screwed with normal TCP. At 10-Gig, a 64k buffer would be even more ridiculous (0.05 ms). Not all switch manufacturers may agree... I'm personally not a big fan of TSO or TOE. They both add a lot of complexity to the network stack, and have other downsides. The *best* way to solve these problems is to engineer technologies to use larger packet sizes. Even at 9k (or better yet 16k) the advantages of these offload schemes is vanishingly small. (Though if a TOE can do zero-copy receive, this is a win over what currently exists, but I think there are other ways to do that as well.) The Linux kernel may not be able to do too much to encourage deployment of larger MTUs, but NIC vendors probably can. -John - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
