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

RE: [EFM] RE: EPON TDMA



Charles,
 
Thank you for the prompt response.  I agree with you.  The other side of
the argument
trying not to get into SLA/QOS standardization at this forum is also:
 
1. SLA/QOS is end to end.  I don't believe this group, being only at the
edge or 'access
side', can dictate SLA/QOS.  
2. SLA/QOS is a service issue.  It is out of the scope from this study
group.
 
-faye

	-----Original Message----- 
	From: Charles Cook 
	Sent: Mon 7/16/2001 11:52 AM 
	To: Faye Ly 
	Cc: glen.kramer@xxxxxxxxxxxx; zhangxu72@xxxxxxxxx;
RHirth@terawave.com; 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@xxxxxxxxx; RHirth@xxxxxxxxxxxx;
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
	
	

winmail.dat