Re: [RE] Stream identification at the MAC SAP
Fred,
In my opinion, your thoughtful scenarios merely demonstrate that the network
you have chosen is not over-provisioned for these applications.
I would propose the following design guidelines for construction of an
over-provisioned Ethernet network for residential applications.
a/ Single wire-speed 100Mbit switch.
-or-
b/ Two wire-speed 100Mbit switches with GigE interconnect.
-or-
c/ Multiple 100Mbit wire-speed switches each uplinked to a central
wire-speed GigE switch.
-----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 7: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
-----Original Message-----
From: Gross, Kevin [mailto:kevin.gross@CIRRUS.COM]
Sent: Friday, November 12, 2004 5:35 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
I think it would be interesting to flesh out and analyze this use case.
-----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 2:04 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
I don't think that when you are potentially running several 20MB/s HD video
streams over your network and then someone wants to copy a DVD sized file
from one computer to another that over-provisioning is going to be up to the
task. You can always find a way to saturate the network. I believe that we
need both QoS and reservation.
Fred Tuck
EchoStar.
-----Original Message-----
From: Gross, Kevin [mailto:kevin.gross@CIRRUS.COM]
Sent: Friday, November 12, 2004 3:51 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
I believe that adequate QoS on a home scale network can be achieved easily
with layer 2 protocols and over-provisioning.
My arguments on this topic were not well received here.
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On
Behalf Of Matt Squire
Sent: Thursday, November 11, 2004 8:04 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Stream identification at the MAC SAP
> Oddly enough, with Residential Ethernet (at least the way some of us
> have been envisioning it), you could really toss the PBX out the
> window without losing any quality of service.
Seems like people have already tossed the PBX out the window, and they're
not having any problems. So if that the benefit of RE, its a little late.
And all of those real-time and synchronized applications working great, and
outside the scope of 802. Which is (not coincidentally) one of my big
questions about some of the work being investigated by this study group -
why does 802 need to define isochronous services at all?
People have been running real-time and synchronized applications over
Ethernet for a long time. Timing issues are generally best addressed
end-to-end at the application layer, and above L2. Not everything has to be
addressed within 802.3.
- Matt