Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [EFM] Minutes of P2MP Optics conference 22nd Aug 20002




Tom,

> Would it be possible to formulate
> the statements below into an Excel data-sheet which could then
> be used as a basis for discussion?

In short, no, no, yes.

1. Cycle overhead depends on size of guard band and the cycle time.
Cycle time however is implementation-dependent, and may not even be
constant.    Number of guard bands in a cycle also can exceed the number
of ONUs (i.e., if some ONUs are polled more than once during a cycle). I
don't think cycle overhead can easily be represented in Excel.

2. Slot overhead also depends on algorithm. It is possible to design
algorithms which will have zero slot-overhead, at the expense of
fairness, or computational complexity, etc.  Also this overhead depends
on multiplexing gain in an ONU, i.e., in case when multiple queues in
one ONU are allowed to transmit in the same slot, the unused remainder
is reduced drastically, even if the assigned slot does not consider
frame delineation.
Thus, again, this overhead is not easy to describe without analyzing a
particular algorithm.

3. Frame overhead can be derived easily given packet size distribution.
These distributions measured on real networks all look similar. They
typically have three modes (there peaks). The mode values are slightly
fluctuate though, and so the resulting overhead would fluctuate, but not
much I suspect. (However, I must admit that when a disruptive
application like Napster appears, the distribution of packet sizes
changes significantly).

The above break-down ignores FEC overhead. As you can see the overhead
would depend on a particular scheduling algorithm chosen. There are too
many options to credibly represent it in Excel. I think, simulation is
the only way to go.

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 8:55 AM
> To: gkramer@xxxxxxxxxxx; Thomas.Murphy@xxxxxxxxxxxx; stds-802-3-
> efm@xxxxxxxx
> Subject: AW: [EFM] Minutes of P2MP Optics conference 22nd Aug 20002
> 
> 
> Hi Glen,
> 
> Thanks for the reply. Would it be possible to formulate
> the statements below into an Excel data-sheet which could then
> be used as a basis for discussion?  I know that there has been some
> work in this direction and my hope is to generate one tool which
> has been accepted by the majority and can be used by all.
> 
> Regards
> 
> Tom
> 
> 
> 
> -----Ursprüngliche Nachricht-----
> Von: Glen Kramer [mailto:gkramer@xxxxxxxxxxx]
> Gesendet am: Freitag, 23. August 2002 18:44
> An: Thomas.Murphy@infineon.com; stds-802-3-efm@ieee.org
> Betreff: 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
> >