Re: [RE] Stream identification at the MAC SAP
This doesn't seem like anything new. Substitute in different applications and different bandwidth possibilities, and this is the same QoS vs overprovisioning argument that has been going on for decades.
I'm just not sure why we're talking about this in 802.3. There are technologies that most often take an overprovisioning philosophy (Ethernet, IP, ...). There are technologies that take a stricter QoS philosophy (FR, ATM, ...). There are even ways to take the traditional packet technologies (Ethernet, IP, ...) and build a strongly QoS-enabled network out of them (MPLS).
If applications/networks need things like bandwidth reservation, dedicated network resources/paths, backup paths, etc., there are methods to do so. If applications/networks can get by with scheduluing/queueing, traffic management at the edge, etc., then there are ways to solve that problem too.
I'm missing the part where the underlying QoS problems are new or different than those that have been around for decades.
- Matt
> -----Original Message-----
> From: owner-stds-802-3-re@IEEE.ORG
> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Tuck, Fred
> Sent: Friday, November 12, 2004 9:44 PM
> To: STDS-802-3-RE@listserv.ieee.org
> Subject: Re: [RE] Stream identification at the MAC SAP
>
>
> First let's talk about basic bandwidth. Today over-provisioning works
> fairly well because most data streams that are being run on
> networks are sub
> megabit. Audio is in the 100-200 Kbit range and most network
> video is 1
> Mbit or less. Things change rapidly when you look at TV
> quality video.
> MPEG-2 encoders have improved to the point where one can broadcast
> reasonable quality video at an average of 3Mbits or so but that is an
> average. Peak rates are 5,6 and up to 8 Mbits per second for
> complex action
> with high detail levels. DVDs that are non-real-time encoded can have
> better quality at 3 Mbits that real time broadcast encoders,
> and that was
> the original average spec. But many producers have found
> that even that is
> still a compromise. So today many DVDs have average data
> rates closer to 7
> or 8 Mbits. As we move to HD we see the 20 Mbit ATSC maximum
> with average
> rates of 17 or 18 Mbs or so. But that is a compromise dictated by the
> maximum amount that can be fit in a 6Mhz TV channel. Real
> peak rates should
> be closer to 25 - 30 Mbits or more to eliminate visual artifacts. Non
> terrestrial channels such as satellite or cable are much
> wider and could be
> used to allow greater peak bandwidth usage. HD DVDs are also not
> constrained by the 20Mbs limit. I don't know the exact
> figure selected but
> I think I have seen values of 38Mbs or more suggested. In
> addition there
> are applications that require merging of streaming video and
> static, or
> dynamic, graphics content. Simple light weight encoders that
> compress 9 or
> 10 to one have been suggested to allow this content to then
> be sent to a
> remote device over 1394 or other networks. We're talking 100
> - 150 Mbs for
> those streams. These are just the normal speed play data
> rates. Do you
> want to allow FF and other trick modes. Many of these modes
> can result in
> data rates of 2,3 even 4 or 5 times the basic data rate.
> Clearly only a few
> of these streams can potentially saturate even a gigabit
> pipe. Add a few
> multi gigabyte file transfers on top of that and you have a
> prescription for
> unhappy consumers as the video on every TV in the home breaks up.
>
>
> Let me illustrate with 3 example use cases that we need to deal with.
>
> For purposes of these examples I will use an switch with
> 100Mbs ports and a
> 100Mbs internal backplane. This may seem limiting but is
> equivalent to
> having two switches connected by a 100Mbs link. It also allows me to
> illustrate the problems with only a few HD streams.
>
> 1. Two DVRs and two TVs on a network each viewing a 20Mbs stream from
> different DVRs: Every link on the network is running at
> 20Mbs with the
> switch running at 40Mbs. One TV user presses 2X FF and now
> two links are
> running at 20Mbs two at 40Mbs and the switch at 60Mbs. Still
> watchable.
> Run both at 2x and you have 80Mbs on the switch. Still OK.
> Then push one
> to 4x and the video on both TVs falls apart as the total
> bandwidth needed of
> 120Mbs exceeds the bandwidth of the switch.
>
> 2. Same two DVRS and two TVs with the addition of a computer
> connected to
> the internet through the LAN. This time you are running 2x
> FF on one TV and
> 3x FF on the other. Total bandwidth 100 Mbs (60Mbs for one
> and 40Mbs for
> the other). On the bleeding edge but possible. Now the computer user
> clicks on a link and the extra demand pushes the switch
> bandwidth over the
> edge and both TV pictures break up.
>
> 3. Same two DVRS and two TVs but now you have two computers:
> Both TVs are
> just watching video at 20Mbs. Now one computer user wants to copy a
> multigigabyte video file off his computer to his laptop. The
> file transfer
> link probably runs at 70 or 80 Mbs (or more). Bandwidth needed by the
> switch is 110 -120 Mbs. Both TVS become unwatchable for the
> 5 to 10 minutes
> the file transfer takes.
>
> Fred Tuck
> EchoStar
>