RE: [EFM] Necessity of DBA mechanisms ...
I have been observing this mail thread and glad to see a lot
of interesting points being raised. It is unclear to me,
however, how did this thread jumped from "Necessity of DBA
mechanism ..." to "how can DBA be achieved?"? Can someone
who can kindly summarize the 'necessity' or the requirements
for DBA for me? I have collected these so far:
1. Fully utilize un-used bandwidth. (This is based on there is
a static bandwidth allocation scheme already exists, or else there
is no un-used bandwidth issue. Is this right?)
2. Support upper layer SLA/QOS. This includes bandwidth, burst
and delay. For each paramter there are two OAM implications,
provisioning (QOS) and monitoring (SLA).
Anything else? Thanks.
-faye
-----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=-