Date: Sat, 20 Jun 1998 00:20:11 -0700 From: bmah@CA.Sandia.GOV (Bruce A. Mah) To: Open Systems Networking <opsys@mail.webspan.net> Cc: spork <spork@super-g.com>, Joel Ray Holveck <joelh@gnu.org>, root@bmccane.maxbaud.net, hackers@FreeBSD.ORG Subject: Re: TweakDUN Message-ID: <199806200720.AAA24228@stennis.ca.sandia.gov> In-Reply-To: Your message of "Sat, 20 Jun 1998 01:51:24 EDT." <Pine.BSF.3.95.980620013654.20127D-100000@orion.webspan.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--==_Exmh_4681088P Content-Type: text/plain; charset=us-ascii If memory serves me right, Open Systems Networking wrote: > On Fri, 19 Jun 1998, spork wrote: > Because for each 1500 byte packet sent over > the MTU link with say a latency of 533ms for dialup, it would take 533ms > for a 1500 byte packet. Now if your using an MTU of 576 and transfer the > same 1500 byte packet with latency of 533ms, you have to send 3 packets of > 536 bytes @ 533ms latency each. It isnt rocket science to see why for > anything BUT interactive traffic where all your traffic will fit inside > your MTU your gonna loose and loose big. Ummm. Let me offer my corrections to this. According to some hurried math, a 1500 byte packet takes about 520 ms to send via a 28.8Kbps link (assuming 10 bits per byte due to stop/start bits, but not counting link-level framing). A 576-byte packet is going to take about 200 ms. Where you *do* lose is the fact that for each of those packets, you have 40 bytes of headers (20 IP + 20 TCP) that you can't lose for data. So you can use 1460/1500 = 97% of the bytes in a packet for "real data", or 536/576 = 93% of the bytes. (Again, discounting link-level framing overheads.) Therefore, to transfer your data via three smaller packets is going to be a bit longer, but not three times longer. Of course this assumes that the TCP flow control algorithm is actually going to *let* you send those packets back to back...at the start of a TCP transfer, that won't be the case. But once the TCP window opens up, with either MTU, that modem link should be running at capacity (assuming the modem is the bottleneck, and no loss). After that point, performance differences would be caused due to header overheads. > So why in gods name people think > an MTU of 576 is the "internet standard" AND their actually believing it > astonishes me. It's mentioned in RFC 1122 (see my previous mail), but I agree that anyone who interprets that spec as meaning that a dialup link needs an MTU of 576, and no more, is dead wrong. > Well you can tell im tired cause im > ranting and probably making no sense. So im going to bed. > Ill probably kick myself for what I just wrote when I read it in the > morning but I am sure some of its right. Ditto. G'night. :-) Bruce. --==_Exmh_4681088P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBNYtiqqjOOi0j7CY9AQG8UwP9GqrMfVUy1g8CGNWK8+j9nTMzn4D9qrSj ORBLXvUl4bTs8rKM24Vb4HKO//thou0QgXYsOyKYn9X7jBBTL+NSCMXlNTVjH4TQ CtrFJU0S3hU121oIIwdCL4bgLGMiNnRdySjpbg6iGG0iaUKwi82OqI1gGwIQpdUy ZddOnQ4uR9M= =vddJ -----END PGP MESSAGE----- --==_Exmh_4681088P-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199806200720.AAA24228>