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