RE: [EFM] Necessity of DBA mechanisms ...
So, is the assumption of TDM approach at the MAC/PHY layer the only way to
guarantee bandwidth for proper SLA mechanism. Just like the CSMA/CD
approach, the TDMA is just the opposite side of the spectrum, where instaed
of a free for all to try sending when ever the node needs to, a completely
controlled and monitored approach is decided. How is the node which will
grant the time slots to the other nodes be decided upon ? (May be this is
already discussed in some previous email which I missed, earlier)
Sukanta Ganguly
Chief Architect
Carrier9 Networks
Phone (408)-746-0400
FAx (408)-730-9441
-----Original Message-----
From: owner-stds-802-3-efm@majordomo.ieee.org
[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Ayyagari,
Deepak
Sent: Monday, July 23, 2001 11:33 AM
To: 'Harry Hvostov'; 'Roy Bynum'; 'Menard, Francois'; Ajay Gummalla
Cc: stds-802-3-efm@ieee.org
Subject: RE: [EFM] Necessity of DBA mechanisms ...
Roy
My thoughts on this thread:
- I agree with Harry that it isnt enough to have layer 3 mechanisms for
providing QoS and enabling SLAs. how can a layer IP flow reserving
bandwidth be assured it will be granted the desired bandiwdth, in the right
quanta and at the right times ( thereby affecting delay and jitter) if the
MAC/PHY dont accomodate the flow along with other flows sharing the link ?
- Regarding unsolicited grant services UGS, I do not understand what you
mean by "unstable infrastructure". the cable plant is extremely stable from
a BER perspective and the DOCSIS 1.1 protocols are very stable in
multiplexing flows with different bandwidth/delay/jitter requirements.
Current platforms support 1000-2000 subs over 1X4 (DS X US) quite
efficiently, with the subs being voice (using UGS) and data with both best
effort and guaranteed service (different schedulers like RTP can be used).
- Delay and Delay Variance in TDMA systems can be much higher than "ps". The
variance will depend on a. The number of ONUs and slot duration b. is the
TDM scheme adaptive c. nature of traffic processes
- TDM delay variance is negligible ONLY in systems with voice traffic where
the BW requirements are periodic and deterministic (based on the vocoders).
That is why fixed TDM is popular in voice only systems. It is easy to
demonstrate that the delay variance and mean in a fixed TDM system both grow
much higher than adaptive schemes when you have bursty traffic (Poisson or
self similar).
- Statistical Multiplexing is a phenomenon by which bandwidth utilization
efficiencies are generated by effective multiplexing of bursty flows. The
exact amount of stat mux gain is very dependent on a. the statistical nature
of traffic b. how the streams are multiplexed. the number 20 % that was
bandied about earlier is applicable to a very specific example only. The
gains can be much greater. My own presentation (July EFM) shows delay gains
which are orders of magnitude better for stat mux systems compared to fixed
TDMA with Poisson (bursty ) traffic.
- With increasing split ratios, 1Gbps isnt all that much BW and the need for
efficient BW utilization grows especially in the presence of complicated
SLAs (including T1 service, best effort data. various data rates etc).
We all agree that the last mile carriers will need flexibility to define and
implement SLAs. The only way to accomplish this is to enhance the 802.3
MAC/PHy mechanisms to enable request/grant scheduling. All in my humble
opinion of course.
Deepak Ayyagari
> -----Original Message-----
> From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
> Sent: Monday, July 23, 2001 12:43 PM
> To: 'Roy Bynum'; Harry Hvostov; 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 ...
>
>
>
> Roy,
>
> That is what's done today with POS links - I didn't invent
> it. I am not sure
> what you are advocating in cases where competing traffic
> flows share the
> link.
>
> We used to demo to customers a network on which VoIP calls
> had to coexist
> with data traffic. Without QoS the VoIP calls were fine on
> lightly loaded
> network. Then we would start big file transfers, throw in a
> couple of flood
> pings and bingo - VoIP calls would start crackling.
> Get QoS going (e.g. DiffServ), assign EF to VoIP flows at each
> router/switch, and VoIP calls are back in business.
>
> Really cheap!
>
> Harry
>
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Saturday, July 21, 2001 5:03 AM
> To: Harry Hvostov; 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,
>
> 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=-
>