Re: [EFM] RE: EPON TDMA
Charles,
More people in the task force need to know what services providers such as
who you and I work for need to make EFM infrastructure deployment pay for
itself. By the way, unless an Ethernet infrastructure is over-subscribed,
it does not need QOS. The inherent reliability and data stability preclude
the need.
Thank you,
Roy Bynum
At 02:19 PM 7/18/01 -0600, Charles Cook wrote:
>Roy,
>
>I agree. For a while there I was getting concerned that some folks were
>thinking
>best effort was all we needed to accomplish with EFM. I'm interested in both
>business and residential subscribers, and assume that SLAs and QoS to support
>certain services will be necessary.
>
>Charles
>
>Roy Bynum wrote:
>
> > Charles,
> >
> > If the EFM TF does not deliver an infrastructure will directly support
> > services with SLAs then there is no market for EFM technology. The low
> > margins for best effort, statistically multiplexed services is so low that
> > they may not even be in business unless they raise their prices within the
> > next year. The cost of infrastructure remains the same. Talk to your
> > accounting organization about how much it costs per Mb per distance to
> > deploy your network. Talk to your accounting department about how much it
> > costs for right of way to put fiber into and though buildings. Talk to you
> > accounting department about how much it costs for power and other
> > facilities to house and operated the equipment that you put your services
> > over. The Internet service providers are charging about as little as ~$180
> > per Mbps for IP wholesale bandwidth, yet many of them are spending well
> > over $200 per Mbps to provide that service. (These costs include
> > facilities, operations, back office systems, engineering, and
> > administration.) Private line services are well over $500 per Mbps and
> > cost about the same as, and sometimes less than the IP best effort
> > services. If a service company is to stay in business, it has to be
> > profitable and to have the ability to provide high margin services in
> > addition to the low margin services. This is an issue that has to be
> > addressed by EFM.
> >
> > Thank you,
> > Roy Bynum
> >
> > At 12:52 PM 7/16/01 -0600, Charles Cook wrote:
> >
> > >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