RE: [EFM] Video distribution
Richard,
The SONET transmission stream is divided into 8000 "frames" with section,
and line overhead for each frame. Additionally within the frame, multiple
"paths", each with their overhead are included in each frame. If you will
examine these overheads, you will find that the vast majority of it is
involved with some OAM function or other. In this context, each SONET
protocol frame is actually an OAM frame specific to the SONET
protocol. SDH, SDHJ and 10GbE WAN PHY also have OAM frames that are very
similar to SONET OAM frames.
The customer traffic in the SONET transmission facility level OAM frame is
referred to a the "payload". Since there are multiple "circuits" or
"paths" in each OAM frame, each customer's specific "circuit" or encoded
data can be called a customer specific path payload.
The OAM frames in the SONET protocol are at the subscriber network facility
level while the OAM frames in EFM are at the customer data stream
level. For Ethernet over SONET/SDH and 10GbE WAN PHY facilities, the EFM
OAM frames would be transmitted as part of the specific customer path
payload data stream, totally invisible to the transmission OAM frames and
the transmission system operations management.
A transmission OAM frame gets transmitted each 125us. (T1/E1 framing is
also based on 125us transmission cycles, but the OAM frame overhead is bit
interleaved instead of transmitted as a overhead block or frame.) The
transmission cycle of 125us means that each specific customer "circuit"
path payload gets multiplexed into the transmission bit stream, only every
125us. The customers bit aligned data stream get "pushed" to a higher bit
rate within a short "window" in the transmission bit stream that is framed
by the transmission protocol OAM overhead. This process is what I referred
to as the "OAM overhead window".
The OAM overhead transmission cycle of 125us introduces a "slotting" effect
to the latency of each specific customers data stream, when it gets mapped
in to the transmission bit stream the way that it is done with X.86
(Ethernet over "SONET"). When an application receives the transmitted data
after going through the CPE switch systems, that "slotting" effect gets
translated to latency variance. This is where the 125us of latency
variance is caused by the transmission system in an X.86 EOS/EPL service to
a customer.
Thank you,
Roy Bynum
At 09:44 AM 9/11/2002 -0400, Townsend, Richard L, JR (Rick) wrote:
>Roy,
>I sent yor email to several in-house folks here and they were confused
>about the phase "because of the OAM overhead window" in the third
>paragraph below. Could you give more details on your thoughts there?
> Rick
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Monday, September 09, 2002 9:27 PM
>To: Mccammon, Kent G.; 'limb@xxxxxxxxxxxx'; Mccammon, Kent G.;
>stds-802-3-efm@ieee.org
>Subject: RE: [EFM] Video distribution
>
>
>
>Kent,
>
>I spent a lot of time at WorldCom in 1998 and 1999 understanding the
>relationship that the characteristics of the transmission facility and
>protocols have on the quality deliverability of different kinds of video
>services. I found that while a video stream will burst to the available
>bandwidth, as long as the bandwidth can deliver a "screen" within the
>allowable time for it to be decoded and displayed, the bandwidth can be
>restricted to close to that of the average of the video data stream
>rate. This goes for streaming video as well as interactive video.
>
>The issue with interactive video is not the bandwidth as much as it is with
>the latency variance inherent with the transmission facility and
>protocols. With low latency variance, streaming video and interactive
>video becomes a consistent stream with fixed, predictable,
>utilization. The more that there is a latency variance, the more that
>higher bandwidth burst traffic has be supported in order to support the
>"screen" rate. Traditionally, IP routers have not been very good at
>controlling latency variance. This is where the higher bandwidth
>requirements for video comes in.
>
>Latency variance for non-blocking Ethernet switches, in non overload
>conditions, is the bit time delta between the largest frames and the
>smallest frames. Latency variance for Ethernet over SONET/SDH (X.86) is
>125us because of the OAM overhead window.
>
>At present, EPON appears to be headed for a latency variance in the
>milliseconds. This might do for streaming video to residential
>customers. I do not think that it will do for any type of high end
>interactive video, regardless of the available bandwidth. If any kind of
>bandwidth gain is applied to the EPON deployment, it will be no better than
>what is in the copper facilities today.
>
>Streaming video can be "buffered" to compensate for latency
>variance. This, however, increases the cost of the video display equipment
>because of the additional complexity in managing the "buffered"
>stream. The least expensive would be a system that only needs to buffer a
>single "screen" before each "refresh". I do not know if the current EPON
>proposals will support that.
>
>Thank you,
>Roy Bynum
>
>
>
>At 01:33 PM 9/9/2002 -0700, Mccammon, Kent G. wrote:
>
> >John,
> >I agree with your comments about higher efficiency when broadcasting video
> >to all VDSL nodes. The PON capacity is a constraint for designing the
> >system. VOD of course changes the numbers as that traffic would be node
> >specific and customer specific depending on the type of VOD service. If the
> >PON throughput looks to be insufficient considering all services needs;
> >broadcast, VOD, telephony, and data services, an operator could plan for a
> >smaller split ratio to the VDSL node. The differential path loss
> >(attenuation range) specification of the optics should be made broad enough
> >to handle PONs with low splits for VDSL, for example 1x4 while other
> >operators deploy for large splits for FTTH such as 1x32 architectures. Thus,
> >the operator could have architecture flexibility in the selection of the PON
> >split ratio for the services planned.
> >-Kent
> >
> >
> > > -----Original Message-----
> > > From: John Limb [mailto:limb@xxxxxxxxxxxx]
> > > Sent: Monday, August 26, 2002 9:50 AM
> > > To: 'Mccammon, Kent G.'; stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] Video distribution
> > >
> > >
> > > Kent,
> > > I'm a little confused. Perhaps you could straighten me
> > > out. If you are distributing digital video from the OLT to
> > > ONUs (even if connected to a VDSL
> > > DSLAM) I would not think that you would need to have an
> > > unused slot remainder since the OLT scheduler could start one
> > > packet as soon as the previous one finished. If you were
> > > sending packets from the ONT to the OLT then I could see that
> > > slot remainders could occur.
> > > If you are serving several hundred subs then you would
> > > probably want to do mostly broadcasting rather then VOD. You
> > > would probably want to use variable rate video coding (rather
> > > than constant rate) in order to get a little more efficiency
> > > and some statistical averaging. Even so, I suspect that most
> > > packets would be max size (as Hugh says).
> > > If you assume an average rate of 3 Mb/s for a high
> > > quality video stream (probably even a little high for some of
> > > the newer VBR codecs) 200 streams would take about 600Mb/s
> > > leaving (plenty?) of room for other data, again confirming Hugh.
> > >
> > > John
> > >
> > > -----Original Message-----
> > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
> > > Mccammon, Kent G.
> > > Sent: Friday, August 23, 2002 6:22 PM
> > > To: 'gkramer@xxxxxxxxxxx'; Thomas.Murphy@xxxxxxxxxxxx;
> > > stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] Minutes of P2MP Optics conference 22nd Aug 20002
> > >
> > >
> > >
> > > Glen,
> > > Referring to your comment about frame size distribution from
> > > actual traffic.
> > >
> > > > The size of unused slot remainder depends on frame size
> > > distribution.
> > > > This distribution for today's traffic is known and there
> > > exist formula
> > > > to calculate this unused remainder (for the case when assigned slot
> > > > size has no correlation to the frame sizes).
> > >
> > > Does anyone in the group have a traffic sample from a network
> > > transporting digital video streams to give frame size
> > > distribution? For example, a traffic sample for digital video
> > > over fiber to a VDSL ONU to serve several hundred VDSL lines
> > > to a residential gateway. That scenario may be a good one to
> > > look at for traffic on a residential GigaPON connected to
> > > multiple VDSL ONU locations with data and switched digital
> > > video content.
> > >
> > > -Kent
> > >
> > > > -----Original Message-----
> > > > From: Glen Kramer [mailto:gkramer@xxxxxxxxxxx]
> > > > Sent: Friday, August 23, 2002 9:44 AM
> > > > To: Thomas.Murphy@infineon.com; stds-802-3-efm@ieee.org
> > > > Subject: RE: [EFM] Minutes of P2MP Optics conference 22nd Aug 20002
> > > >
> > > >
> > > >
> > > > Tom,
> > > >
> > > > This is to address action item #2 from the minutes.
> > > >
> > > > 2. Efficiency model based on guard bands and traffic type - P2MP
> > > > group?
> > > >
> > > >
> > > > There are 3 types of overhead (or bandwidth loss):
> > > >
> > > > 1. Cycle overhead. This is overhead used by guard bands (including
> > > > CDR). It is measured as a number of guard bands in one cycle. This
> > > > number at least equal to the number of ONUs, but may be
> > > even larger if
> > > > we grant per LLID and there are multiple LLIDs per ONU.
> > > >
> > > > 2. Slot overhead. This overhead arises when granted slot does not
> > > > take into account frame delineation in a buffer. Since
> > > frames cannot
> > > > be fragmented, a frame that doesn't fit in the remainder of a slot
> > > > will be deferred to next slot (in next cycle), leaving current slot
> > > > underutilized.
> > > >
> > > > The size of unused slot remainder depends on frame size
> > > distribution.
> > > > This distribution for today's traffic is known and there
> > > exist formula
> > > > to calculate this unused remainder (for the case when assigned slot
> > > > size has no correlation to the frame sizes).
> > > >
> > > > Few protocol proposals consider how to eliminate unused
> > > slot remainder
> > > > completely, but it looks like it will require changes to the frame
> > > > format. P2MP group is still debating about it.
> > > >
> > > > 3. Frame overhead. That includes IFG and headers. Nothing
> > > we can do
> > > > about it.
> > > >
> > > > Glen
> > > >
> > > > > -----Original Message-----
> > > > > From: owner-stds-802-3-efm@majordomo.ieee.org
> > > > [mailto:owner-stds-802-3-
> > > > > efm@xxxxxxxxxxxxxxxxxx] On Behalf Of Thomas.Murphy@xxxxxxxxxxxx
> > > > > Sent: Friday, August 23, 2002 1:57 AM
> > > > > To: stds-802-3-efm@ieee.org
> > > > > Subject: [EFM] Minutes of P2MP Optics conference 22nd Aug 20002
> > > > >
> > > > > Hello All,
> > > > >
> > > > > First off I apologise for sending this mail to the
> > > > > EFM reflector, however, a number of issues arose which
> > > > > are relevant for other groups.
> > > > >
> > > > > The next phone conference is planned for next Thursday
> > > > > at the old time of 11:00 Eastern
> > > > >
> > > > > Regards
> > > > >
> > > > > Tom
> > > > >
> > > >
> > > >
> > >
> > >
> > >