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