Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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