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

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