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

RE: [EFM] Necessity of DBA mechanisms ...

Side band circuits are jitterless, as near as makes no difference i.e.
stratum one compliant, and very low latency. If EFM can get the circuits to
the POP then they can be aggregated to T3 and put on an existing SONET ring
in the metro, thus to the Class 5 switch at the CO. The data delivered over
EFM goes to a switch / router at the POP and back to the CO on a different
OC circuit or a different lambda. Job done.

I can't see xLECs throwing out their SONET/SDH infrastructure for a few
years yet. There are a lot of dollars on a lot of balance sheets. This is
despite the fact that in the NGN e-mailer of last week (John McQ promoting
the NGN conference this fall) says that most corporates will throw out their
PBX systems and convert to VoIP in the next twelve months. I'll believe that
when I see it.

'Don't fix it if it ain't broke' makes a lot of sense in the current
economic conditions for most businesses. Evolution not revolution may be.
The CLEC / ISP service revolution in the late 1990s didn't really work, in
fact it is what created the current economic conditions (well, that and 3G
license madness in Europe).

Apologies if this last paragraph is too political :-).


-----Original Message-----
[]On Behalf Of Harry
Sent: 16 July 2001 18:49
To: 'Roy Bynum'; Harry Hvostov; 'Menard, Francois'; Ajay Gummalla
Subject: RE: [EFM] Necessity of DBA mechanisms ...


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.


-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Monday, July 16, 2001 10:20 AM
To: Harry Hvostov; 'Menard, Francois'; Ajay Gummalla
Subject: RE: [EFM] Necessity of DBA mechanisms ...


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:

>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
>VoIP will require the use of various compression algorithms, not just
>Hence, the ePON link will need to support isochronous traffic with
>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
>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
>favor reinventing the wheel.
>-----Original Message-----
>From: Menard, Francois [mailto:f.menard@xxxxxxxxxxxxxx]
>Sent: Monday, July 16, 2001 7:24 AM
>To: Ajay Gummalla
>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.
>In EFM, there are 3 issues, and DBA may only apply to only one of the
>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
>order to develop products surrounding issue #3, saying that there is
>consensus in this group that DBA is required is not accurate.  Saving 20%
>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
>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
>those seeking the development of P2MP EPON.  I do not claim however that
>of my specific issues represent "consensus in this group".  One of the
>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
>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
>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.