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
> >
>
>