RE: [EFM] Necessity of DBA mechanisms ...
Harry,
That is a very complicated and bandwidth expensive way of doing what should
not need to be done in the first place.
Thank you,
Roy Bynum
At 04:15 PM 7/19/01 -0700, Harry Hvostov wrote:
>Roy,
>
>POS link access is mediated by CQS (classification, queuing, and scheduling)
>mechanisms applied to IP packets. More hands on QoS control at HDLC level
>can be had by stuffing user packets with 0x7E bytes to tweak aggregate POS
>link b/w.
>
>Harry
>
>-----Original Message-----
>From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
>Sent: Wednesday, July 18, 2001 3:11 PM
>To: Harry Hvostov; 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,
>
>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=-