RE: [EFM] Video distribution
Limb,
What if you are wanting to do high quality video conferencing? The one
thing that high quality interactive video can not stand is too much delay
and "data jitter". The issues that Kent brought up are just a few that
will be seen with high quality interactive video. Broadcast video, which
is what you are talking about, is already at commodity returns. In order
to justify fiber deployment, other services that will draw premium returns
needs to be supportable. This is where interactive video comes in.
Business services require security and fixed, dedicated bandwidth,
otherwise they are just another commodity packet service. There have been
many attempts over the last seven years to migrate the business community
toward packet type services. Other than at, or close to commodity returns,
it has not been successful. There has been a lot of market hype and some
success for specific customers, but for the most part, business customers
that buy the high bandwidth services demand full use of the bandwidth,
bi-directionally, even during "busy hours". (This is where a major service
provider, who will remain un-named, failed with their ATM
offering. Customers were so dissatisfied with the VBR services during
"busy hours" that the service provider had to go back and provide the CBR
services at the VBR prices. With ATM, it cost the service provider more to
provide those CBR services than it would have if they had provided simple
SONET based leased circuits which the ATM CBR service was emulating. That
service provider has since discontinued that ATM service.) I don't believe
that service providers want to repeat the un-named service provider's
experience, even if it is now called Ethernet.
Thank you,
Roy Bynum
At 12:50 PM 8/26/2002 -0400, John Limb wrote:
>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
> > >
> >
> >