Making stuff go fast on a network, part 1

re: Making stuff go fast on a network, part 1

Carlos — Wed, 10 May 2006 01:32:34 GMT

There's a minor typo:

"which is exactly the same as if the receiver hadn't received the ack in the first place"

s/ack/data/

re: Making stuff go fast on a network, part 1

KJK::Hyperion — Wed, 10 May 2006 04:54:41 GMT

Personally, the single most enlightening thing I've ever heard about networking and congestion control is Raymond's "the pipe (in bits) is bandwidth (in bits/second) multiplied by latency (in seconds); you want your window to be as large as your pipe". Not even Stevens could have put it more clearly and concisely

re: Making stuff go fast on a network, part 1

Heine — Wed, 10 May 2006 10:48:25 GMT

Larry,

"There is an interesting consequence to that last guarantee: It turns out that the sender can't start transmitting B until after it knows that the receiver has received A. Why is that?"

Probably a minor mix up. This makes no sense until you read the following paragraph.

re: Making stuff go fast on a network, part 1

Heine — Wed, 10 May 2006 10:51:00 GMT

Apologies, I should learn how to read properly or work on my attention span.

re: Making stuff go fast on a network, part 1

nick — Wed, 10 May 2006 12:54:23 GMT

"Personally, the single most enlightening thing I've ever heard about networking and congestion control is Raymond's "the pipe (in bits) is bandwidth (in bits/second) multiplied by latency (in seconds); you want your window to be as large as your pipe". Not even Stevens could have put it more clearly and concisely"

Its also known as the bandwidth-delay product, refer
http://www.speedguide.net/bdp.php for a simple BDP calculator.

re: Making stuff go fast on a network, part 1

nick — Wed, 10 May 2006 13:43:25 GMT

"Remember from my comment yesterday: It takes effectively the exact same amount of time to send 1 byte of data as it does 1400 bytes."

Just a note there for anybody reading that...thats true as you said on an ethernet network. Not so on the Internet. In other words, we're talking about (as you rightly titled this post) making stuff go fast on "a" network, not a bunch of networks connecting two endpoints.

re: Making stuff go fast on a network, part 1

Virgulino Ferreira — Wed, 10 May 2006 18:08:39 GMT

Another minor typo:

"on Ethernet the maximum frame size (or MSS, Maximum Segment Size) is 1500 bytes"

This is the Maximum Transmission Unit (MTU).

Interesting Finds

Jason Haley — Wed, 10 May 2006 20:29:21 GMT

re: Making stuff go fast on a network, part 1

J.C. — Thu, 11 May 2006 03:29:39 GMT

Hi Larry. I think you should perhaps expand or write another entry explaining why SMB performance over a WAN is so degraded, and maybe you could provide solutions/hacks on how to fix it. Thx.

-jc

re: Making stuff go fast on a network, part 1

Mike — Thu, 11 May 2006 21:14:44 GMT

"If the sender sends three packets in the order A-B-C"

You should probably say messages instead of packets. For TCP at least the sender has little if any control over how the message gets broken up into packets.

It seems like a minor nit but network newbies have immense trouble understanding this point and write lots of buggy networking code because of it.

re: Making stuff go fast on a network, part 1

cnettel — Fri, 12 May 2006 11:50:19 GMT

nick: Really? Ok, we can have other fragmentation limits, but the latency should still stay much higher than the actual transmission time for the packet. (Of course, if everyone decides to inflate their bandwidth requirement by 139900 %, performance will suffer for all.)

re: Making stuff go fast on a network, part 1

nick — Fri, 12 May 2006 14:04:28 GMT

cnettel:

Yup, was talking about fragmentation limits...what happens when you hit a network which can't handle large packets?
[ refer http://en.wikipedia.org/wiki/Maximum_segment_size ]

Fragmentation occurs, and while that doesn't affect TCP delay since you aren't waiting for acks, the time taken to send the data now depends on the kind of network being transited. So the guarantee mentioned (1 bytes vs 1400 bytes taking the same amount of time) is no longer absolutely valid.

re: Making stuff go fast on a network, part 1

Mu — Fri, 12 May 2006 14:46:18 GMT

"It turns out that the sender can't start transmitting B until after it knows that the receiver has received A."

I'm not sure I believe this. Surely the axiom applies only to the interface to the connection oriented protocol? That is, the protocol guarantees to the layer above that it (the layer above) will receive the "message" in the correct order - but whether the connection protocol /itself/, internally, sends and receives everything in order or not is irrelevant.

re: Making stuff go fast on a network, part 1

LarryOsterman — Fri, 12 May 2006 16:19:40 GMT

Mu,
That's right, but remember my comment about buffering - the stack <i>could</i> send out of order and complete out of order IF AND ONLY IF it could guarantee that the receiver had resources to buffer up packet B until packet A is received. Packet A might never be received, in which case the stack would have wasted the resources.

That means you have an easy way of mounting a denial of service attack against the server. Send A.1, B.1-B.20, C.1-C.20, ... Z.1-Z.20. The server would have to keep all those packets in memory waiting on A.2 to arrive.

All the connection oriented protocols I know of solve the out-of-order arrival by simply waiting on the ack of A before B is sent.

It turns out that this ordering behavior is critical, and I'll be talking about this in the 3rd article in this series (I got nailed with a horrible cold so haven't written anything after this post).

re: Making stuff go fast on a network, part 1

Mu — Mon, 15 May 2006 10:43:48 GMT

Ok, I sit corrected. I'd still change your "can't" to a "shouldn't" or "must not" though :)

Making things go fast on a network, part 2

Larry Osterman's WebLog — Mon, 15 May 2006 21:15:18 GMT

Sorry about the delay - I got nailed by a nasty sinus infection on Tuesday night last week that took...

re: Making stuff go fast on a network, part 1

Tom H — Thu, 18 May 2006 16:52:25 GMT

Larry, I'm not sure I understand your discussion of the DOS attack above (or your original point, really). My viewpoint is pretty Internet-centric, so it may be that NetBEUI does that, but I don't think TCP does.

First of all, TCP doesn't send anything that the user can identify as packets or frames; it sends a stream of bytes, and reserves the right to divvy those up arbitrarily into packets on the network; they're delivered to the receiver as a stream of bytes without any message boundaries. TCP is perfectly happy to start sending B.1 and B.2 even before it knows that A.20 has been received; that's part of what the sliding window is for. TCP handshake establishes the flow control window size, and every TCP header updates that window size, so the sender always knows whether or not the receiver can buffer the packets it's sending, and the receiver can bound the size of the DOS attack.

Making things go fast on a network, part 3

Larry Osterman's WebLog — Wed, 14 Jun 2006 03:11:31 GMT

Now I want to pop the stack up a bit and talk about messages.&nbsp; At their heart, connection oriented...

I wish Larry hadn't written that...

Tales from the Crypto — Tue, 27 Jun 2006 07:13:37 GMT

Oh, Larry, Larry, Larry...
Articles 1 and 2 were great - really necessary reading to a lot of would-be...

Larry Osterman s WebLog Making stuff go fast on a network part 1 | Portable Greenhouse

Mon, 01 Jun 2009 13:23:16 GMT

PingBack from http://portablegreenhousesite.info/story.php?id=758