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 |
|jstracke(_at_)incentivesystems(_dot_)com |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
ietf_censored(_at_)carmen(_dot_)ipv6(_dot_)cselt(_dot_)it, which
is a sublist of ietf(_at_)ietf(_dot_)org(_dot_) Not all messages are passed.
Decisions on what to pass are made solely by Raffaele D'Albenzio.