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

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

-----Original Message-----
From: Glenn Algie [mailto:algie@xxxxxxxxxxxxxxxxxx]
Sent: Tuesday, July 17, 2001 11:10 AM
To: 'Harry Hvostov'; 'Roy Bynum'; 'Menard, Francois'; Ajay Gummalla
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Necessity of DBA mechanisms ...

Show me a DOCSIS asic that can run at a 1000Mbps? 25MBPS is the likely hw boundry for DOCSIS this year it seems.

Recommend 802.3EFM should refrain from SARing the ethernet packet due to heavyweight protocol/hardware costs. Suggest the smallest manageable slot be at max size size ethernet frame. Engineering equation should then play with bandwidth, number of outstations and minimized guard bands.

-----Original Message-----
From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
Sent: Tuesday, July 17, 2001 1:35 PM
To: 'Roy Bynum'; Harry Hvostov; Harry Hvostov; Harry Hvostov; 'Menard,
Francois'; Ajay Gummalla
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Necessity of DBA mechanisms ...

Check out the IETF RFC-2205 RSVP Flow/TSpecs for definition of data
latency/jitter bounds for traffic flows over IP networks.

I am not sure what you mean by unstable infrastructure. DOCSIS transports
Ethernet transparently with up to 2,000 subs per downstream channel - rather
stably.

-----Original Message-----
From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
Sent: Tuesday, July 17, 2001 10:26 AM
To: Harry Hvostov; Harry Hvostov; Harry Hvostov; 'Menard, Francois';
Ajay Gummalla
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Necessity of DBA mechanisms ...

The only reason that unsolicited grant service is used for VoIP today is
that it is running over an infrastructure that does not have any inherent
stability. I could be wrong, but as far as I know, none of the IETF
standards have specifications for data jitter(data latency variance), or
data loss. The Internet today can have a data latency variance as great as
200ms. GbE has an inherent data latency of 12us. TDM latency variance is
measured in ps. If this group was only going to produce another Internet
quality infrastructure, then they are wasting their time.

>Roy,
>
>By definition, unsolicited grant service is used to enforce stringent
packet
>jitter and delay constraints for isochronous traffic flows such as VoIP.
The
>requests are implicit, resulting in additional b/w conservation.
>
>Fundamental to this is the process of traffic flow admission, based on the
>parameter set which specifies concrete inter-packet jitter and delay
>constraints. In other words, two or more active traffic flows on the shared
>link imply that the jitter and delay bounds are met for all of them
>simultaneously.
>
>Harry
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Monday, July 16, 2001 10:54 AM
>To: Harry Hvostov; Harry Hvostov; 'Menard, Francois'; Ajay Gummalla
>Cc: stds-802-3-efm@ieee.org
>Subject: 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@xxxxxxxxxxxxxx]
> >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@xxxxxxxxxxxxxx]
> > >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=-