RE: [EFM] Necessity of DBA mechanisms ...
Harry,
Actually, I have exactly the opposite point. I am less concerned about
overall latency than I am latency variance. Unsolicited grant service will
vary the latency based on the grant requests from the other UNIs as
well. This causes an overall lack of predictability and pre-determination
that can not be defined very well in a high margin service SLA.
Thank you,
Roy Bynum
At 10:48 AM 7/16/01 -0700, Harry Hvostov wrote:
>Roy,
>
>Precisely my point. Interpacket jitter is hard to control if ONUs are
>allocated time slots based on the network split ratio rather than the period
>that the G.7xx vocoder requires. An example of dealing with this is DOCSIS
>unsolicited grant service that places strict bounds on packet delay and
>jitter by enforcing slot allocations of appropriate size and period.
>
>Harry
>
>
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@mindspring.com]
>Sent: Monday, July 16, 2001 10:20 AM
>To: Harry Hvostov; 'Menard, Francois'; Ajay Gummalla
>Cc: stds-802-3-efm@ieee.org
>Subject: RE: [EFM] Necessity of DBA mechanisms ...
>
>
>Harry,
>
>VoIP, uncompressed, uses less than 1 Mbps of bandwidth. The real problem
>with VoIP is latency variance. More often than not, IP vendor throw
>excessive bandwidth into the mix to provide low utilization and that have
>low base latency and hopefully reduce latency variance to address this
>issue. Having as much as 50Mbps with the low latency variance that
>Ethernet traditionally has will provide more than bandwidth for even
>broadcast quality interactive video applications that are even more
>sensitive than voice.
>
>Thank you,
>Roy Bynum
>At 09:49 AM 7/16/01 -0700, Harry Hvostov wrote:
>
> >Francois,
> >
> >I agree that P2P topologies may not present the DBA challenge.
> >
> >However, wasting 20% on a Gigabit link represents 200 Mbps - compared to 2
> >Mbps on HFC. Hence the need to use intelligent b/w allocation on ePON
> >remains.
> >
> >VoIP will require the use of various compression algorithms, not just
>G.711.
> >Hence, the ePON link will need to support isochronous traffic with
>arbitrary
> >periods. This requires dynamic b/w allocation, not a rigid TDM scheme. The
> >same applies to IP video with its periodic variable size grant needs.
> >
> >B/w overhead associated with dynamic requests can be further reduced if a
> >traffic flow parameters are described a priori. An example is an
>isochronous
> >traffic flow which requires
> >grants of fixed size at periodic intervals - without explicit requests sent
> >by ONUs.
> >
> >In addition, the request/grant scheme offers direct feedback of ONU state,
> >including such critical measurements as queue occupancy.
> >
> >In general, I have a feeling that those of us familiar with DOCSIS tend to
> >favor the dynamic request/grant protocol approach, while those that are
>not,
> >favor reinventing the wheel.
> >
> >Harry
> >
> >
> >-----Original Message-----
> >From: Menard, Francois [mailto:f.menard@muni-ims.qc.ca]
> >Sent: Monday, July 16, 2001 7:24 AM
> >To: Ajay Gummalla
> >Cc: stds-802-3-efm@ieee.org
> >Subject: RE: [EFM] Necessity of DBA mechanisms ...
> >Importance: High
> >
> >
> >
> >Ajay wrote: > It seems to me that there is a consensus in this group that
> >dynamic adaptation is required though there are differences on how
> >exactly and on what time scale the adaptation is done.
> >
> >Ajay,
> >
> >In EFM, there are 3 issues, and DBA may only apply to only one of the
>three:
> >
> >Issue #1) For P2P EFM, DBA is clearly not an issue.
> >Issue #2) For P2P EPON, DBA is clearly not an issue
> >Issue #3) For P2MP EPON, DBA may be an issue,
> >
> >For those of us not seeking that IEEE wastes time delaying issues 1 and 2
>in
> >order to develop products surrounding issue #3, saying that there is
> >consensus in this group that DBA is required is not accurate. Saving 20%
>of
> >bandwidth at Gigabit speeds is not as crucial as saving 20% of bandwidth
> >over bandwidth-limited HFC systems. The complexity and costs associated
> >with shielding DBA head-end grants with security mechanisms protecting
>them,
> >do not represent, in my view, an effort that is worth the costs of more
> >expensive CPE and head-end equipment for EFM.
> >
> >My personal agenda with EFM is being distracted by those seeking DSL EFM
>and
> >those seeking the development of P2MP EPON. I do not claim however that
>one
> >of my specific issues represent "consensus in this group". One of the
>merit
> >of dealing with all EFM issues as a whole right now is that we can discern
> >what constitutes consensus from what does not. We agree that minimal
> >modifications to the MAC for O&M to indicate link failures and signal
>levels
> >are a good idea. We also agree that single-strand tranceivers are worth
> >standardizing. While we have discussed this, little discussions surround
> >how 802.1s/w/x will integrate to EFM. We need to look at this from a
> >systemic point of view. While mine surrounds FTTx P2P EFM, others may have
> >different priorities for different markets. I am willing to consider that
> >issue #1 is being delayed, but not at the expense of seeing claims of
> >consensus being reached on issues which I think have nothing to do with
> >ensuring the development of cost-effective FTTx P2P EFM products.
> >
> > > If a Voice packet arrives behind a large data packets, mechanisms to
> >transmit
> >voice packet ahead of the data packet will be useful.
> >
> >A G.711 packet arriving behind a 1500 bytes data at one megabit per second
> >is clealy not the same than a G.711 packet arriving behind a 1500 bytes
> >packet at one gigabit per second.
> >
> >-=Francois=-