[95535] in North American Network Operators' Group
Re: Jumbo frames
daemon@ATHENA.MIT.EDU (Stephen Sprunk)
Fri Mar 30 12:36:53 2007
From: "Stephen Sprunk" <stephen@sprunk.org>
To: "Andy Davidson" <andy@nosignal.org>
Cc: "North American Noise and Off-topic Gripes" <nanog@merit.edu>
Date: Fri, 30 Mar 2007 11:33:59 -0500
Errors-To: owner-nanog@merit.edu
Thus spake "Andy Davidson" <andy@nosignal.org>
> The original poster was talking about a streaming application -
> increasing the frame size can cause it take longer for frames to fill a
> packet and then hit the wire increasing actual latency in your
> application.
>
> Probably doesn't matter when the stream is text, but as voice and video
> get pushed around via IP more and more, this will matter.
It's a serious issue for voice due to the (relatively) low bandwidth, which
is why most voice products only put 10-30ms of data in each packet.
Video, OTOH, requires sufficient bandwidth that packetization time is almost
irrelevant. With a highly compressed 1Mbit/s stream you're looking at 12ms
to fill a 1500B packet vs 82ms to fill a 10kB packet. It's longer, yes, but
you need jitter buffers of 100-200ms to do real-time media across the
Internet, so that and speed-of-light issues are the dominant factors in
application latency. And, as bandwidth inevitably grows (e.g. ATSC 1080i or
720p take up to 19Mbit/s), packetization time quickly fades into the
background noise.
Now, if we were talking about greater-than-64kB jumbograms, that might be
another story, but most folks today use "jumbo" to mean packets of 8kB to
10kB, and "baby jumbos" to mean 2kB to 3kB.
S
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
