Re: [RE] Stream identification at the MAC SAP
Bill,
>> While it won't take care of attempts to send more real-time
>> traffic than a link supports, the work from the Congestion
>> Management group should enable throttling back of the file
>> transfers and non-real time traffic so that those applications
>> don't disturb the real-time video applications.
From my observations, congestion management would 'eventually'
adapt to 'stable' loading conditions so that 'fewer' frames
will be lost due to congestion.
I don't believe 'eventually' is fast enough, 'stable' can be
ensured, or 'fewer' frame losses is acceptable in real-time audio.
I used single quotes to differentiate between what I have
deduced from observing this group, which may differ from
their official position(s).
While the CM group may be addressing valuable load-leveling
optimizations, I don't think this is sufficient to ensure
real-time transfers (real time, I believe, is not a goal
for this group).
DVJ
David V. James
dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Shvodian
>> William-r63101
>> Sent: Saturday, November 13, 2004 2:05 PM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Stream identification at the MAC SAP
>>
>>
>> While it won't take care of attempts to send more real-time
>> traffic than a link supports, the work from the Congestion
>> Management group should enable throttling back of the file
>> transfers and non-real time traffic so that those applications
>> don't disturb the real-time video applications.
>>
>> By the way, there must be a better way to handle fast forward
>> than to send 2, 4, 8, 16 X the traffic across the net,
>> especially since much of it will get thrown away anyway.
>> Otherwise, I don't see how any QoS scheme prevents you from
>> going over your allocated bandwidth, without serious
>> over-allocation for fast forward. If you have a 100 Mbps link
>> and you try to send an 8X HD signal without loss you are out of luck.
>>
>> Bill
>>
>> -----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 k!
>> now 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