Variation in Delay (jitter) may be an important motivation to bound the size of the MTU on FTTH. If one wishes to do voice (or other delay critical service) across this link, then one cannot use large playback buffers to mask jitter. A data under-run caused by a delay excursion would then result in a gap in the audio stream (which could be interpolated, but not without pain to Fax machines and the like...)
ATM used segmentation to help with the jitter problem. Time critical traffic did not have to wait for a big packet to complete before gaining access to the channel; big packets were chopped into chunks and time critical traffic could get priority access to the line as soon as the end of the previous chunk. With higher speed links, waiting for the completion of an in-progress big packet can be contemplated, provided that the big packet is not too big. On a 100Mbps link, a conventional Ethernet frame lasts less than 0.2 mSec. Multiply the frame size by 10 or 100 and the max delay goes up by 10 or 100. Certainly, there will be other causes of delay (upstream MAC in a shared media environment, the coalescing of voice traffic to reduce the header inefficiency, etc). Constraining the maximum frame size bounds the jitter component introduced by waiting for in-progress packets to be transmitted. Bob PS I believe the above argument also holds for MPEG-2 video. If one were to transport base-band MPEG-2 streams across a FTTH plant, as PixStream, Minerva and others contemplated, then the delay variation expected governs the size of the playback buffer needed in the set top box. The larger that buffer must be, the slower your channel change times will be. At 12:30 PM 2/25/2002 -0500, John Stracke wrote: >Stephen M. Bellovin wrote: > > >If you're doing > >uncompressed voice (compression makes this effect worse), a 1500 byte > >packet holds 214 ms of voice at the (U.S.) standard rate of 56K bps. > >That's already beyond the delay budget, just for that one hop, > >On the other hand, that's assuming POTS-grade audio quality. Some people >could have use for higher-quality audio. For example, radio stations >prefer to use high-quality audio when doing interviews with people in >remote locations. Musicians could use CD-quality audioconferencing to >practice together remotely (for example, if Big Stars from different >continents are preparing for a live show together); at 176K bytes/second, >a 1500-byte MTU is less than a single millisecond, meaning you'd have to >route more than 1000 packets per second. (And that's just for stereo; > >And then there's video; given FTTH, it could be practical for a TV news >program to do an IP-based videoconference when it needs to interview >somebody remotely. Since by then we'd be talking about HDTV, they'd need >a huge bit rate; individual frames could easily turn out to overflow the >1500-byte MTU. > >I know this is stuff that's been talked about for a long time, and has >remained impractical (I used to work in videoconferencing); but the >biggest part that makes it impractical has been bandwidth. FTTH would >increase that bandwidth, so it does seem like something for a body working >on FTTH to consider. > >/========================================================\ >|John Stracke |Principal Engineer | >|[EMAIL PROTECTED] |Incentive Systems, Inc.| >|http://www.incentivesystems.com |My opinions are my own.| >|========================================================| >|Cogito ergo Spud. (I think, therefore I yam.) | >\========================================================/ > >- >This message was passed through [EMAIL PROTECTED], which >is a sublist of [EMAIL PROTECTED] Not all messages are passed. >Decisions on what to pass are made solely by Raffaele D'Albenzio.
