RE: [EFM-P2MP] EPON efficiency white paper
Glen,
It is great that you have written the white paper which may prove to be an important piece of work for the EPON community. However, it must withstand scrutiny without a doubt.
The delineation overhead calculation is based on utilizing proprietary messaging between OLT and ONU. The standard draft does not describe queuing thresholds. In a multi-vendor case (other cases do not apply for mass market) even the cleverest of schedulers with deficit counters (as in Shreedhar et al.) etc. does not have better choices but to grant a static slot to ONUs during periods of congestion.
Many people rely on SNMP as a rescuer from shortcomings in the .3ah standard. But as soon as vendors have implemented schedulers that use different messaging between OLT and ONU, it is practically impossible to change the situation using SNMP. Who will have the motivation to do the job anyway because it's just another 10 % ;)?
The white paper should state that the values hold only for single vendor case or if the unlikely interoperable SNMP MIB threshold variables come into existence. A calculation based purely on the current EPON standard draft, without relying on the provided hooks for scheduling optimization, should be presented first.
Antti
> -----Original Message-----
> From: ext Glen Kramer [mailto:glen.kramer@teknovus.com]
> Sent: 22 May, 2003 22:25
> To: Pietilainen Antti (NRC/Helsinki); stds-802-3-efm-p2mp@ieee.org
> Subject: RE: [EFM-P2MP] EPON efficiency white paper
>
>
> Antti,
>
> I stated this in the paper and will reiterate it here again:
> There are many ways to make EPON inefficient, if one wants
> to. For example, one can make a cycle time very small - few
> hundred us, or one may design a dumb scheduler that grants
> static slots. But this is not intrinsic EPON overhead - this
> is just an inefficient design.
>
> Several approaches are available for the situation that you
> describe.
>
> Static SLA does not mean a static slot. Consider for example
> a Deficit Round Robin scheme (M. Shreedhar, and G. Varghese,
> "Efficient Fair Queuing Using Deficit Round-Robin," IEEE/ACM
> Transactions on Networking, vol. 4, no. 3, pp. 375-385, June
> 1996). You may grant based on the threshold and skip a
> grant when service exceeds the SLA.
>
> Also, in this example, thresholds do not need to be set
> dynamically. Setting them once through a mechanism like SNMP
> or OAM will be fine.
>
> I tried to be conservative in my efficiency estimations. If
> the cycle time is FIXED, there is at most one grant that
> will not be based on a threshold, and will be based on the
> remaining cycle time. Of course, the cycle time need not be
> fixed (or can be nearly fixed), s.t. there will be no
> truncated grants and the delineation overhead will be zero.
>
> Hope this clarifies the issue.
>
> Glen
>
> > Hello all,
> > About the delineation overhead part where it was
> > calculated that only one grant in a cycle will be of wrong
> > length compared to the length of offered packets. I got
> > different results based in assumption that the wrong
> > length applies to all grants in a cycle:
> >
> > If the cycle time is 1.5 ms and there
> > is 32 users who all get one slot each cycle, about 100
> > Mbit/s is lost out of 1 Gbit/s if each user looses 595
> > bytes each cycle. That is about 10%. If, on the other
> > hand, a user has an SLA of static 10 Mbit/s, that user
> > will actually get only 10 Mbit/s - 595 x 8 / 1.5 ms = 6.8
> > Mbit/s of bandwidth. Thus, that user looses 32%.
> >
> > This calculation applies to the situation where the
> > network is congested and the queues in ONUs are longer
> > than can be granted. Of course, there is not much point in
> > doing the calculation in other than congested situation.
> >
> > There was an attempt to standardize a) an effective way
> > for sending thresholds from OLT to ONUs and b)
> > interpretation what the thresholds mean but it failed. In
> > a network where ONUs and OLT are from different vendors,
> > the traffic losses that I calculated are real. Is this
> > pessimistic view right or wrong?
> >
> > Antti
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: ext Glen Kramer [mailto:glen.kramer@teknovus.com]
> > > Sent: 10 May, 2003 00:08
> > > To: stds-802-3-efm-p2mp@ieee.org
> > > Subject: [EFM-P2MP] EPON efficiency white paper
> > >
> > >
> > > Friends of EPON,
> > >
> > > There still exists a perception of inadequate efficiency
> > of
> > > EPON. Many times I encountered inaccurate statements
> > > claiming the EPON efficiency to be extremely low.
> > >
> > > I attached a white paper explaining all the overhead
> > > components and justifying the values of configuration
> > > parameters. I tried to be as conservative as possible
> > and
> > > considered all overhead components, even those with
> > > negligible values.
> > >
> > > Please, review it for accuracy and give me your
> > comments.
> > > You may freely distribute this white paper.
> > >
> > > Thanks,
> > > Glen
> > >
> > > ---------------------------
> > > Glen Kramer
> > > Teknovus, Inc.
> > > glen.kramer@teknovus.com
> > > Office: (707)665.0400 x115
> > > Mobile: (530)306.5039
> > > ---------------------------
> > >
> > >
> > >
>
>
>
>