Subject: Re: IPv6 MTU issues in FTTH applications

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 22 Feb 2002 18:06:21 -0500

In message <[email-masked]>, "Tony Hain" writes
:
>n the example here in particular, putting voice over
>large packets is intuitively the wrong thing to do, and making those
>frames larger than 1500 simply makes the problem worse. 

It's not just intuitive, it's quantitative.  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, and 
without taking into account the jitter buffer, speed of light delay, 
etc.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: "John Stracke" <[email-masked]>
Date: Mon, 25 Feb 2002 12:30:55 -0500

Stephen M. Bellovin wrote:

>If you're doing 
>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-masked]   |Incentive Systems, Inc.|
|http://www.incentivesystems.com |My opinions are my own.|
|========================================================|
|Cogito ergo Spud. (I think, therefore I yam.)           |
\========================================================/

---

From: "Robert M. Enger" <[email-masked]>
Date: Mon, 25 Feb 2002 18:15:37 -0500

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:
>-
>This message was passed through [email-masked], which
>is a sublist of [email-masked]. Not all messages are passed.
>Decisions on what to pass are made solely by Raffaele D'Albenzio.