RE: [EFM] RE: EPON TDMA
Glen,
I disagree with your specific limitation of the definition of the term
"statistical mulitplexing". ANY time that data frames/packets from
multiple sources are allowed to intermingle in an asynchronous fashion
it is "statistical" instead of a time or wavelength multiplexing. Things
like prioritization, QOS, etc, are simply mechanism to attempt change the
characteristics of a statistical multiplexing technology. "DBA" is nothing
but a term that is being used to hide the fact that you are attempting to
push a statistically multiplexing solution as if were something else. As
a service provider, I might be able to make such an infrastructure
deployment pay for itself in the low margin residential market, but it will
never provide high margin business services that will make a service
provider want to make a major investment in it.
Thank you,
Roy Bynum
At 10:19 AM 7/18/01 -0700, glen.kramer@xxxxxxxxxxxx wrote:
>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