RE: [EFM] RE: EPON TDMA
Roy,
That was a continuation of a thread where I tried to explain that
statistical multiplexing is not the same as DBA. At least in those
definitions I refer to, stat muxing relies only on instantaneous traffic
conditions in its attempt to squeeze in more bandwidth. DBA relies on more
intelligent mechanisms like prioritization, SLAs, etc. MPLS uses flow
classification (i.e. creating forwarding equivalence classes) which is
beyond simple stat muxing. ATM also reserves bandwidth based of specific
flow needs. I agree that for the lowest priority class both MPLS and ATM
will resort to stat muxing. But then they don't provide QOS for that class,
in the sense that packet (cell) loss will be affected by ambient traffic and
is not predictable in any short interval of time. It is predictable though
in the long run as a statistical average.
Hope that clarifies it.
Glen
Glen,
You said "You are right stat muxing doesn't allow QOS at higher layers."
I do not know where you get the idea that stat muxing does not allow QOS at
higher layers. MPLS relies on data traffic that has already been
statistically multiplexed to differentiate the traffic flows in order to do
QOS. QOS is very more often used in the context of IP protocols and
implementations than anywhere else that I have heard, other than ATM, which
is also a statistically multiplexing technology.
Thank you,
Roy Bynum
At 12:01 PM 7/17/01 -0700, glen.kramer@xxxxxxxxxxxx wrote:
>Bob,
>
>You are right stat muxing doesn't allow QOS at higher layers. That is what
>I meant earlier saying that it may be harmful in EFM area. Same problem is
>present in a switch in P2P scenario if the switch relies only on stat
muxing
>(i.e., statistical mechanisms) to aggregate traffic into a
bandwidth-limited
>uplink. Clearly, switch must be smart enough to differentiate between two
>simultaneously arrived packets to prioritize them. Switch also must take
>care of controlling bandwidth consumption by each user, and thus it must
use
>DBA rather then just stat muxing.
>
>The EPON is not any different if we remember to keep it simple. If
>timeslots are allocated to each ONU, that essentially will mean a specific
>pipe to each user. In equal allocation this pipe will have guaranteed
>bandwidth of 60+ Mbps in 1:16 case or 30 Mbps in 1:32 deployment, or each
>pipe may be different based on SLA. MAC in this case is in a full duplex
>mode.
>
>We should understand that efficient aggregation of multiple flows (classes,
>users, etc.) is a worry of those who buy bandwidth, not those who sell it.
>Thus, "last mile" provider is interested in utilizing its upstream link and
>users care about efficient utilization of whatever bandwidth they buy. If
>bursty traffic wastes 20% of bandwidth that user paid for, the user has a
>choice of implementing shaping mechanisms, or buying more bandwidth.
>
>Another question is how to charge for bonus best effort bandwidth? It is
>easy to charge for fixed pipe irrespective of its utilization. Will users'
>ability to burst data up to X Mbps offset his/her drive to upgrade to more
>guaranteed bandwidth?
>
>This was not a reply to Bob's posting, but rather a comment on DOCSIS
>discussion.
>
>Glen
>
>
>-----Original Message-----
>From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
>Sent: Tuesday, July 17, 2001 11:04 AM
>To: stds-802-3-efm@ieee.org
>Subject: RE: [EFM] RE: EPON TDMA
>
>
>I think the point is that in a statistically shared medium, as is
>traditional/original Ethernet (and possibly EPON, depending upon the
>definitions within EFM), the implementation of QoS at higher layers cannot
>rely on layer two for packet delivery. Therefore any QoS implemented at
>layer three and above is fundamentally flawed.
>
>Make the Ethernet point to point full duplex and packet delivery is
>guaranteed, as near as makes no difference, so long as the PHY is intact.
>There is no accounting for back-hoe, or 'JCB failure' as the more
>politically correct say in the UK (the non-correct usually say something
>xenophobic regarding the origins of the JCB (back-hoe) operator). Redundant
>paths is why SONET/SDH supports dual paths, (is it not?), and why IEEE is
>also working on RPR. We just need to make sure that alternate carriers
don't
>use the same trunk for both paths :-). It has been known.
>
>Bob
>
>
>-----Original Message-----
>From: owner-stds-802-3-efm@majordomo.ieee.org
>[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Charles
>Cook
>Sent: 16 July 2001 19:53
>To: Faye Ly
>Cc: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx; RHirth@xxxxxxxxxxxx;
>stds-802-3-efm@ieee.org
>Subject: Re: [EFM] RE: EPON TDMA
>
>
>
>I don't think that trying to do a true SLA over Ethernet is the
requirement.
>Other
>methods at higher layers should be doable.
>
>Charles
>
>Faye Ly wrote:
>
> > Something I need clarification on: As far as I know, there are multiple
> > solutions to SLA
> > or QOS in the IP world such as diffserv or MPLS TE (Traffic
> > Engineering). EFM provides
> > bandwidth allocation and implementation which can be a part of the
> > higher layer parameters?
> > Or it is our intention to try to do a true SLA over Ethernet? If this
> > is the case, what application
> > will that be? Thanks.
> >
> > -faye
> >
> > -----Original Message-----
> > From: Charles Cook
> > Sent: Mon 7/16/2001 7:47 AM
> > To: glen.kramer@xxxxxxxxxxxx
> > Cc: zhangxu72@yahoo.com; RHirth@terawave.com; stds-802-3-efm@ieee.org
> > Subject: Re: [EFM] RE: EPON TDMA
> >
> > This is turning into an interesting discussion. One thing to
> > consider for EFM
> > is that from a carrier perpective, EFM will most likely not be a
> > peer-to-peer
> > implementation. Particularly if a carrier needs to manage SLAs
> > etc. DBA and
> > stat muxing will both be essential for success. If portions of
> > this are not
> > addressed in the lower layers, we may be sacrificing some
> > channel efficiencies.
> > We will need to strike an appropriate balance. I'm in agreement
> > that we should
> > be careful not to use statements like,
> >
> > "Ethernet never did that..." or "Ethernet traditionally does
> > that...".
> >
> > However, I do believe we also need to find a sufficiently
> > elegant solution so
> > that we can take advantage of the Ethernet cost model.
> >
> > Charles
> >
> > glen.kramer@xxxxxxxxxxxx wrote:
> >
> > > These are comments for both Xu's and Ryan's postings.
> > >
> > > First let's not mix stat muxing and dynamic bandwidth
> > allocation. These are
> > > different concepts.
> > >
> > > DBA is a method allowing "just-in-time" bandwidth allocation
> > to an
> > > application that requires it. As an example, consider a
> > network carrying
> > > voice and data. In the absence of voice traffic all the
> > bandwidth is given
> > > to data traffic. When new voice call arrives "some
> > mechanisms" will reduce
> > > the bandwidth available to data traffic and will allocate it
> > to voice
> > > traffic. This bandwidth will be guaranteed to voice traffic
> > in a sense that
> > > each voice packet won't need to struggle to get its share of
> > the bandwidth.
> > > When voice call completes, the same "mechanisms" will return
> > the bandwidth
> > > back to data traffic.
> > >
> > > Statistical multiplexing is a way of statistically allocating
> > channel
> > > bandwidth, i.e., stealing chunks of bandwidth when other users
> > (node) failed
> > > to do so. "Statistical" nature means that bandwidth available
> > to a user
> > > will converge to some fixed value only when averaged over long
> > observation
> > > time. But there is no way to predict how much bandwidth will
> > be available
> > > to a node in any given short interval of time.
> > >
> > > Ethernet (specifically CSMA/CD) uses statistical multiplexing.
> > DBA, on the
> > > other hand, was never part of Ethernet. But when we think of
> > Ethernet in
> > > the First Mile, we realize that this is whole new world for
> > the Ethernet,
> > > where it has never gone before. Suddenly stat muxing in its
> > current form
> > > (CSMA/CD) becomes very harmful due to its statistical nature.
> > Yes, we want
> > > to utilize bandwidth efficiently, but most importantly - we
> > need to provide
> > > SLAs to users. CSMA/CD is a non-deterministic service:
> > packets may collide
> > > some number of times and then be discarded. DBA in this new
> > world becomes
> > > important, as we want to be able to deliver all services:
> > voice, video,
> > > data, etc.
> > >
> > > How this could be solved in EFM? Let's first consider P2P
> > solution as I see
> > > it. In P2P deployment a very smart switch will be located in
> > CO. This
> > > switch will monitor traffic for each user in terms of both
> > volume and
> > > application. As the uplink bandwidth is clearly a limited
> > resource, the
> > > switch will make an arbitration decision of which packets to
> > drop in terms
> > > of both keeping the user within its pipe and maintaining some
> > sort of DBA
> > > within each pipe. We hope the switch will be SLA-aware. Of
> > course, it will
> > > be proprietary to each vendor how switch fabric will be
> > implemented. It is
> > > higher level, above MAC and PHY, and the standard is not
> > concerned with it.
> > > The point is that both decision of how to keep user within its
> > pipe and
> > > execution of this decision are done in the CO.
> > >
> > > Now consider P2MP. In the same way as in P2P, higher layers
> > in OLT will
> > > make a decision how to keep user within its SLA. The only
> > difference is
> > > that execution of this decision and ensuring DBA within user's
> > pipe are
> > > delegated to an ONU. And if in P2P the switch may decide to
> > give entire
> > > uplink bandwidth to one ONU, so in P2MP, the OLT may do so by
> > giving all
> > > timeslots to one ONU, or just by making it one large timeslot.
> > Of course,
> > > real implementation is a bit more complicated: changed ONU
> > state needs to be
> > > propagated to OLT. This may be done through OAM communication
> > channels,
> > > proactively of otherwise, and except increased delay has no
> > side effects.
> > > Letting PHY be timeslot-aware is just a mechanism for ONU to
> > execute the
> > > OLT's decision. OLT may choose to modify timeslot assignments
> > or size as
> > > often as it deems feasible. Specific values of timeslot,
> > frequency of
> > > updates, and algorithm used to make such decisions are all
> > outside the scope
> > > of the project.
> > >
> > > I readily agree with Xu's comment that we need a model to
> > analyze. Once EFM
> > > graduates into a work group and technical work begins, I think
> > we will
> > > proceed by building a simulation model for various approaches.
> > >
> > > On a general note, I would like to suggest to group members to
> > refrain from
> > > comments like "Ethernet never did that..." or "Ethernet
> > traditionally does
> > > that...". Ethernet traditionally supported CSMA/CD, and in
> > 802.3ae it
> > > doesn't anymore. And it never was used in WAN and now it is.
> > Ethernet
> > > never had OAM, and now it will. Without fair amount of
> > "heresy" in each new
> > > project Ethernet would never become ubiquitous protocol as it
> > is now. We
> > > have PAR and objectives to govern our direction. Tradition and
> > religion is
> > > not one of them.
> > >
> > > Thank you,
> > >
> > > Glen
> > >
> > > -----Original Message-----
> > > From: xu zhang [ mailto:zhangxu72@xxxxxxxxx]
> > > Sent: Friday, July 13, 2001 7:28 PM
> > > To: Ryan Hirth
> > > Cc: stds-802-3-efm@ieee.org
> > > Subject: RE: [EFM] RE: EPON TDMA
> > >
> > > I agree with Hirth's opinion, in order to keep the
> > > statistic multiplexing nature of ethernet, the DBA
> > > is needed.
> > > in a large time solt. such as 125us, if the ONU has
> > > large traffic, the time solt may be not enough, if the
> > > ONU has little traffic, the bandwidth utilization will
> > > be reduced a lot. In a fixed size time solt, the DBA
> > > is easy to implement, but in order to achieve high
> > > bandwidth utilization the time solt need to be small,
> > > when using variable size time solt, the DBA is hard to
> > > implement, but it can keep statistic multiplexing
> > > nature of ethernet and at the same time achieve high
> > > bandwidth utilization.
> > >
> > > I think whether the frame will be segmented of not
> > > segmented, how long the time solt will be,
> > > the DBA or SBA(static bandwidth allocate£(c)£¬
> > > using variable size time slot or fixed size time slot,
> > > we need a model to calculate.
> > >
> > > --- Ryan Hirth <RHirth@xxxxxxxxxxxx> wrote:
> > > > Ethernet has always had an inherent form of DBA in
> > > > the fact it allows a
> > > > station with traffic to send at up to the line rate
> > > > or an arbitrated rate
> > > > less than that. However in a connectionless system
> > > > there are no service
> > > > contracts or allocations of that bandwidth, but
> > > > bandwidth of the media is
> > > > divided dynamically. SLAs are features which do not
> > > > belong in the Ethernet
> > > > MAC layer, however dynamic bandwidth allocation is
> > > > inherent within Ethernet
> > > > and that is why Ethernet is so well suited for data
> > > > traffic.
> > > >
> > > > By creating fixed timeslots in the upstream you are
> > > > changing the nature of
> > > > Ethernet. Now the maximum bit rate of one station
> > > > to burst upstream is
> > > > limited to its timeslot. I believe according to the
> > > > AllOptic presentation
> > > > this would be 25 - 50 Mbps/ station (without DBA).
> > > > This creates asymmetry
> > > > which has never been an explicit form of Ethernet.
> > > >
> > > > A new media for Ethernet should present similar
> > > > characteristics of
> > > > traditional Ethernets. There is certain level of
> > > > service which Ethernet
> > > > has. If you increase the latencies across the media
> > > > ten fold, is it still
> > > > Ethernet? The end user will perceive a difference
> > > > in service.
> > > >
> > > > Ryan Hirth
> > > > Terawave Communications
> > > > rhirth@xxxxxxxxxxxx
> > > > (707)769-6311
> > > >
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: jc.kuo@xxxxxxxxxxxx
> > > > [ mailto:jc.kuo@xxxxxxxxxxxx]
> > > > Sent: Friday, July 13, 2001 4:06 PM
> > > > To: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx
> > > > Cc: stds-802-3-efm@ieee.org
> > > > Subject: RE: [EFM] RE: EPON TDMA
> > > >
> > > >
> > > >
> > > >
> > > > As PON is just a new media of Ethernet, the overall
> > > > system will be a base on
> > > > "Switched Ethernet" architecture.
> > > > Under this architecture, bandwidth shaping and
> > > > priority queuing will only be
> > > > done in the switch fabric. In the MAC and PHY, a
> > > > mechanism which allow
> > > > flexibly assign the data rate may benefit the DBA
> > > > implementation but DBA
> > > > algorithm will not be implemented as part of MAC and
> > > > PHY layer function.
> > > >
> > > > There is always trade-offs between delay and
> > > > utilization. Reduce the guard
> > > > band and do the packet fragmentation will help the
> > > > bandwidth utilization,
> > > > then the delay can be minimized. EPON is under the
> > > > umbrella of Ethernet,
> > > > keep the Ethernet frame integrity is one of the
> > > > religions of 802.3 team,
> > > > packet fragmentation is not considered as an option
> > > > for the standard.
> > > >
> > > > JC Kuo
> > > > jc.kuo@xxxxxxxxxxxx
> > > > Alloptic, Inc.
> > > > 2301 Armstrong St.
> > > > Livermore, CA 94550
> > > > Phone: (925) 245-7641
> > > > Fax: (925) 245-7601
> > > > www.alloptic.com
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: glen.kramer@xxxxxxxxxxxx
> > > > [ mailto:glen.kramer@xxxxxxxxxxxx]
> > > > Sent: Friday, July 13, 2001 2:55 PM
> > > > To: zhangxu72@xxxxxxxxx; glen.kramer@xxxxxxxxxxxx
> > > > Cc: stds-802-3-efm@ieee.org
> > > > Subject: [EFM] RE: EPON TDMA
> > > >
> > > >
> > > >
> > > > Dear Xu,
> > > >
> > > > I think I know what confused you in the presentation
> > > > as I got several
> > > > similar questions.
> > > >
> > > > Timeslot is not an analog to a cell. While, from the
> > > > slide 4 in the
> > > > presentation you may conclude that one timeslot is
> > > > only large enough to hold
> > > > one maximum size packet, that is not the case.
> > > > Timeslot in our example was
> > > > 125 us, which equals to 15625 byte times. Then you
> > > > can see that in the
> > > > worst case it will have 1518 + 4(VLAN) +
> > > > 8(preamble)+12(IPG) - 1 = 1541
> > > > bytes of unused space at the end of timeslot
> > > > (assuming there is data to be
> > > > sent and no fragmentation). With realistic packet
> > > > size distribution (like
> > > > the one presented by Broadcom), the average unused
> > > > portion of the timeslot
> > > > is only about 570 bytes. That gives channel
> > > > efficiency of 96%, or
> > > > accounting for 8 us guard bands - 90%
> > > >
> > > > DBA is a separate question. While it may be
> > > > important for an ISP to have
> > > > DBA capabilities in their system, I believe it will
> > > > not be part of the 802.3
> > > > standard. But a good solution would provide
> > > > mechanisms for equipment
> > > > vendors to implement DBA. These mechanisms may
> > > > include, for example, an
> > > > ability to assign multiple timeslots to one ONU or
> > > > to have timeslot of
> > > > variable size. Grant/Request approach is trying to
> > > > achieve the same by
> > > > having variable grant size.
> > > >
> > > > Having small timeslots will not solve QOS either.
> > > > Breaking packet into
> > > > fixed small segments allows efficient memory access
> > > > and a cut-through
> > > > operation of a switch where small packets are not
> > > > blocked behind the long
> > > > ones (and it assumes that short packets have higher
> > > > QOS requirements). In
> > > > such a distributed system as EFM is trying to
> > > > address (distances in excess
> > > > of 10 km) the gain of cutting through is negligible
> > > > comparing to propagation
> > > > delay or even the time interval before ONU can
> > > > transmit in a time-sharing
> > > > access mode (be that TDMA or grant/request method).
> > > >
> > > >
> > > > Thank you,
> > > >
> > > > Glen
> > > >
> > > > -----Original Message-----
> > > > From: xu zhang [ mailto:zhangxu72@xxxxxxxxx]
> > > > Sent: Thursday, July 12, 2001 7:01 PM
> > > > To: glen.kramer@xxxxxxxxxxxx
> > > > Cc: stds-802-3-efm@ieee.org
> > > > Subject: EPON TDMA
> > > >
> > > > hi, glen:
> > > > I had seen your presentation file about EPON TDMA
> > > > in
> > > > PHY, it help me a lot to understand your EPON
> > > > system.
> > > > We had developed the first APON system in china,
> > > > when
> > > > I think of the TDMA of EPON, I think though the
> > > > uplink
> > > > data rate is 1Gbits/s when shared by 16 or 32 users
> > > > is
> > > > still not enough, so the dynamic bandwidth
> > > > allocate(DBA) protocal must be a requiremant
> > > > especially when take care of the QoS performance. In
> > > > DBA protocal, in order to achieve high performance
> > > > the
> > > > time slot need be to small, I think why not we
> > > > divide
> > > > the ethernet packet to 64 byte per solt, it is often
> > > > used in ethernet switch when store packet in SRAM.
> > > >
> > > > best regards
> > > > xu zhang
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Get personalized email addresses from Yahoo! Mail
> > > > http://personal.mail.yahoo.com/
> > > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get personalized email addresses from Yahoo! Mail
> > > http://personal.mail.yahoo.com/
> >
> >
> >
> >
------------------------------------------------------------------------
> > Name: winmail.dat
> > winmail.dat Type: DAT File
>(application/x-unknown-content-type-dat_auto_file)
> > Encoding: base64