RE: [EFM] Necessity of DBA mechanisms ...
Harry,
In a Packet over SONET implementation, what is the Layer 2 protocol that is
used to provide QOS?
Thank you,
Roy Bynum
At 09:33 AM 7/18/01 -0700, Harry Hvostov wrote:
>Roy,
>
>QoS implementation typically relies on layer 2 mechanisms - RSVP is the
>signaling protocol that is layer 2 independent. The actual scheduling part
>of QoS relies on Layer 2 specific implementation. With shared access
>networks such as ePON there has to be a way to schedule transmissions for
>competing traffic flows. As such, QoS cannot be implemented at Layer 3
>alone.
>
>QoS allows precise differentiation among these competing traffic flows down
>to the application flow level, if needed. Without this differentiation, all
>application flows get the same (i.e. best effort) treatment. Hence the low
>margin service common denominator.
>
>You can certainly throw additional bandwidth to resolve the QoS issues.
>However, this does not scale, especially on subscriber access networks which
>typically see substantial oversubscription to be economical.
>
>
>Harry
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Wednesday, July 18, 2001 7:47 AM
>To: Harry Hvostov; Harry Hvostov; Harry Hvostov; Harry Hvostov; 'Menard,
>Francois'; Ajay Gummalla
>Cc: stds-802-3-efm@ieee.org
>Subject: RE: [EFM] Necessity of DBA mechanisms ...
>
>
>Harry,
>
>I think that you have just validated my argument. You are looking at a
>higher layer protocol, not Ethernet. In the RFC that you reference, the
>timing is about how a RSVP message functions and times out. It has
>absolutely nothing to do with the reliability or stability of a customer's
>data inside of a subscription service network.
>
>Over the last two years, several companies, referred to as "legacy free
>service providers", that have started to provide services over GbE as the
>service infrastructure. There are more than one. Each uses a different
>vendor's data switches for equipment. The only common denominator is that
>they use dark fiber access to by-pass the ILEC. They provide Ethernet VPNs
>using VLAN tags to transport IP protocol traffic. Their infrastructure
>costs are very close to what any CLEC would have to do a dark fiber by-pass
>of an ILEC copper facility. This is a low cost, low margin service. Over
>the existing legacy free service providers' infrastructure, a customer can
>receive service that has a very low data loss, as little as 10-8 data
>frames lost per second. Over the existing legacy free service providers'
>infrastructure, a customer can receive a service that has a very low data
>in-stability, as low as 500us of latency variance end to end over the
>service provider network. This is achieved without the need for QOS.
>
>QOS should not be part of the discussion of the technology requirements for
>EFM. QOS, if it is implemented should be done at a higher layer in the
>service stack. I believe that, like the GbE service infrastructures, if
>EFM technology is done correctly, then QOS will not even be needed at the
>higher service layers.
>
>Thank you,
>Roy Bynum
>
>At 10:35 AM 7/17/01 -0700, Harry Hvostov wrote:
> >Roy,
> >
> >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.
> >
> >Harry
> >
> >
> >-----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 ...
> >
> >
> >Harry,
> >
> >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.
> >
> >Thank you,
> >Roy Bynum
> >
> >At 12:13 PM 7/16/01 -0700, Harry Hvostov wrote:
> >
> > >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=-