Re: [RE] Overprovisioning limitations
Kevin,
My my perspective:
>> These developments may obsolete the "applications expand to fill
>> available bandwidth" argument.
That's been hypothesized many times in the past, and never been true.
Particularly when one considers multiple devices going through one
switch, and the multiplier that implies.
I don't find the argument that SW can't pump at those large rates
very convincing, particulary with Moore's law on processor speeds
and the ability of software to be fixed/bypassed when necessary.
As an interesting number, the link between a CPU and uncompressed
display (hope I didn't miss a decimal point :>):
4.8Gbs = 2Mpixel * 32bits/pixel * 75 frames/sec
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: 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 Gross, Kevin
>> Sent: Thursday, September 02, 2004 11:35 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Overprovisioning limitations
>>
>>
>> The use scenarios I've explored so far produce bottlenecks in
>> media servers
>> before bottlenecks in the network kick in.
>>
>> This should not be surprise as growth in network bandwidth has been
>> consistently outpacing CPU or storage bandwidth growth. On top
>> of that, AV
>> data compression has improved such that bandwidth used by media
>> streams has
>> grown even more slowly.
>>
>> These developments may obsolete the "applications expand to fill
>> available
>> bandwidth" argument.
>>
>> There seems to be lot of concern that putting more devices on the network
>> will place more demands on the network. That's only strictly true for
>> repeater networks (i.e. CSMA/CD Ethernet, IEEE-1394).
>>
>> Bandwidth of a modern switched network scales 1:1 with the size of the
>> network. The uplinks between switches are an exception. Large
>> (enterprise)
>> networks cannot be overprovisioned because uplinks reach a
>> scaling limit. In
>> the scenarios I've explored, I find you don't hit these limits in a home
>> network.
>>
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG] On
>> Behalf Of David V James
>> Sent: Thursday, September 02, 2004 11:25 AM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: [RE] Overprovisioning limitations
>>
>> Kevin,
>>
>> >> 2&3/ It is clear that you don't believe overprovisioning can deliver
>> >> acceptable performance. I would need to work through some use
>> >> scenarios to be convinced. Can you supply?
>>
>> I thought (2) would be clear. No matter what the bandwidth,
>> applications can always use more. And, when I get my fast
>> file-transfer IP extensions, or whatever, I don't want my
>> music to stop when my son offers what appears to be infinite
>> load.
>>
>> There are a variety of high load scenarios. CPU in the garage
>> and display on the desk. Might have seemed too revolutionary,
>> but so is the recent MAC integrated with the display. High
>> performance interactive video, scanning through picture books
>> in real time, etc., etc.
>>
>> I have 5 networked computers right now, and with CE devices
>> that would effectively be increased to 10-15. Its not hard
>> to imagine the cumulative BW exceeding the capacity,
>> particularly if some of the switches are only 100Mb.
>>
>> So, the answer to (2) is that overprovisioning is not possible.
>>
>>
>> Relative to (3), ensuring the assurance that realTimeBw < linkBw
>> is more feasible. However, some latencies get quite large when
>> realTimeSw approaches linkBw, so one would probably have to
>> overprovision quite a bit, or how that the configuration
>> restrictions and large end-point buffers were sufficient.
>>
>> This strategy has a couple of problems, though. Its generally
>> _not_ a good idea to have the end-point devices have large
>> buffers, to cope with the worst-cast topologies. Basically,
>> in this cost sensitive market, they just will not do it.
>> Instead, they will size buffers for the typical topology.
>>
>> So, devices may work _until_ you add one more switch, and
>> then the customer is surprized and hears the clicks/pops.
>>
>> Having bridges reclock the data, relative to the common
>> system cycle time, is preferred since each of the extra
>> switches (that cause the problem to be worse) provides
>> the additional buffer (that resolves the worse problem).
>> Thus, this system inherently scales: only the consumer
>> with many bridges pays for the costs associated with
>> many bridges.
>>
>> DVJ
>>
>> David V. James
>> 3180 South Ct
>> Palo Alto, CA 94306
>> Home: +1.650.494.0926
>> +1.650.856.9801
>> Cell: +1.650.954.6906
>> Fax: +1.360.242.5508
>> Base: 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 Gross, Kevin
>> >> Sent: Thursday, September 02, 2004 8:19 AM
>> >> To: STDS-802-3-RE@listserv.ieee.org
>> >> Subject: Re: [RE] CE applications (was: RE: [RE] Focus of discussions)
>> >>
>> >>
>> >> 1/ I would suggest you have identified synchronous network
>> >> application #2.
>> >> Separately connected speakers require very stable time alignment
>> >> for stable
>> >> stereo imaging.
>> >>
>> >> 2&3/ It is clear that you don't believe overprovisioning can deliver
>> >> acceptable performance. I would need to work through some use
>> >> scenarios to
>> >> be convinced. Can you supply?
>> >>
>> >> -----Original Message-----
>> >> From: owner-stds-802-3-re@IEEE.ORG
>> >> [mailto:owner-stds-802-3-re@IEEE.ORG] On
>> >> Behalf Of David V James
>> >> Sent: Wednesday, September 01, 2004 5:05 PM
>> >> To: STDS-802-3-RE@listserv.ieee.org
>> >> Subject: Re: [RE] CE applications (was: RE: [RE] Focus of discussions)
>> >>
>> >> All,
>> >>
>> >> I was a bit busy and therefore quiet this morning. After reading
>> >> a few notes, a few thoughts might be in order.
>> >>
>> >> 1) Time-of-day synchronization.
>> >> To play back something on two speakers, without drift between
>> >> them, the presence of a common system clock is highly useful.
>> >>
>> >> This "stereo" application requires several clocks (source and
>> >> two destinations) be synchronized accurately, better than can
>> >> be done by an application.
>> >>
>> >> Doing this does not necessarily mean the whole system has to
>> >> be accurately synchronized in its transfers. It only means that
>> >> the errors (delays in sending/receiving clockSync frames) can
>> >> be accurately measured.
>> >>
>> >> For example, the clockSync frame on 1394 may be delays for over
>> >> 1/2 cycle, but that delay is included in the frame that is sent.
>> >>
>> >> 2) Admission control.
>> >> The idea of assigning priorities, followed by hope-and-pray,
>> >> is not very deterministic. I would hate for a second video
>> >> playback, coming from my son watching cartoon downloads,
>> >> to destroy the audio on my important olympics or Friday night
>> >> Mystery on PBS.
>> >>
>> >> The way to avoid this is call setup, admission control, or a
>> >> variety of other terms. The basic point is that your can't use
>> >> high priority traffic until _after_ you have negotiated for its
>> >> usage.
>> >>
>> >> No matter how deterministic the interconnect, without admission
>> >> control all guarantees are null and void.
>> >>
>> >> For example, on 1394 there are protocols for reserving isochronous
>> >> bandwidth on the bus and for communicating such information
>> >> through bridges.
>> >>
>> >> This can perhaps be done in a less time-critical fashion, but
>> >> it is advantageous to have bridges participate (rather than rely
>> >> on a topology-aware central server), so some standard protocols
>> >> may be necessary.
>> >>
>> >> 3) Prioritized delivery.
>> >> With their bandwidths prenegotiated, and admission control
>> preventing
>> >> an overload, simple priority is _almost_ sufficient. There are
>> >> two possible gotcha's, however:
>> >>
>> >> a) Uniformity. Unless negotiated bandwidth is uniformly specified,
>> >> the admission controls can be violated for short time intervals.
>> >> For example, if voice sends every 125us and video sends frames
>> >> at 60Hz, the long burst of video temporarily "drowns" the audio.
>> >> To avoid this, all devices need to have a common impression of
>> >> the time interval for each transfer.
>> >>
>> >> You can think of this as not negotiating for bandwidth, but
>> >> negotiating for bytes-per-cycle, where all applications agree
>> >> on the cycle.
>> >>
>> >> There are advantages in picking cycles used by others, long
>> >> enough for video to be efficient, short enough for audio to
>> >> incur short delays. For example, 1394 uses 125us cycles.
>> >>
>> >> Some folks also use the term "admission control" to describe
>> >> hardware/software that limits the per-cycle transmissions.
>> >> We might therefore want to distinguish between per-call
>> >> and per-cycle admission control.
>> >>
>> >> b) Bunching.
>> >> Just using high priorities does not really provide the desired
>> >> behaviors. High priorities still have high jitter, since the
>> >> best-case time is very small and the worst-case is dependent
>> >> on the statistics of asynchronous/jumbo/synchronous conflicts.
>> >>
>> >> With high jitter, one has the possibility that a station's
>> >> synchronous data from many cycles arrives in one bunch.
>> >>
>> >> This has the effect of increasing the possible delays to
>> >> others, that may have to wait for this "bunch" to complete.
>> >> And, of course, this then has an effect on how long their
>> >> "bunch" can be.
>> >>
>> >> I always get headaches when I try to figure out the worst
>> >> case bunching due to jitter, and the jitter due to bunching.
>> >> While my metro network friends say "Trust us, it works, just
>> >> believe in your SLA", I like to see real proofs.
>> >>
>> >> Real proofs are an absolute necessity. Without them, its hard
>> >> to tell if a testing lab won't find the worst case and slam
>> >> all of your products. After all, that's what test&review
>> >> companies are paid to do.
>> >>
>> >> To avoid this problem, 1394 reclocks synchronous data when
>> >> it passes through bridges. With this tatic, the worst-case
>> >> jitter between two stations doesn't change with additional
>> >> bridges, its only the delay that increases.
>> >>
>> >> Its not that I'm a 1394 zealot, it just that they have a few
>> >> useful examples of possible solutions. There are some limitations
>> >> to the specific implementations on 1394, so I'm not advocating
>> >> a blind acceptance (what doesn't work is nearly as important
>> >> as what did work).
>> >>
>> >> I'm not quite sure if that answers your question. Its a bit hard
>> >> to answer "prove this doesn't break" questions. I prefer to rephrase
>> >> the architecture review questions to "how do we design so that
>> >> we can (relatively simply) prove this always works."
>> >>
>> >> DVJ
>> >>
>> >> David V. James
>> >> 3180 South Ct
>> >> Palo Alto, CA 94306
>> >> Home: +1.650.494.0926
>> >> +1.650.856.9801
>> >> Cell: +1.650.954.6906
>> >> Fax: +1.360.242.5508
>> >> Base: 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 Wadekar, Manoj K
>> >> >> Sent: Wednesday, September 01, 2004 2:55 PM
>> >> >> To: STDS-802-3-RE@listserv.ieee.org
>> >> >> Subject: Re: [RE] CE applications (was: RE: [RE] Focus of
>> discussions)
>> >> >>
>> >> >>
>> >> >> Why can't this configuration use prioritization?
>> >> >>
>> >> >> Say:
>> >> >> Voice : priority 7 (highest)
>> >> >> Video: priority 6
>> >> >> File Transfer : priority 5
>> >> >>
>> >> >> Assuming Strict Priority scheduling at interface
>> (better algos
>> >> >> could
>> >> >> be used for fairness).
>> >> >>
>> >> >> For all practical purposes Voice and Video quality
>> >> will not see
>> >> >> significant degradation. Even through a switch. Jumbo
>> >> frames can
>> >> >>
>> >> >> create more jitter though.
>> >> >>
>> >> >> Thanks,
>> >> >> - Manoj
>> >> >>
>> >> >> -----Original Message-----
>> >> >> From: owner-stds-802-3-re@listserv.ieee.org
>> >> >> [mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf Of
>> >> John Gildred
>> >> >> Sent: Wednesday, September 01, 2004 12:42 AM
>> >> >> To: STDS-802-3-RE@listserv.ieee.org
>> >> >> Subject: Re: [RE] CE applications (was: RE: [RE] Focus of
>> discussions)
>> >> >>
>> >> >> Here is one use case which needs a CE (cheap HW) solution:
>> >> >>
>> >> >> -2 AV (A and B) devices are connected via CAT-5e crossover cable
>> >> >> -the devices have a full duplex gigabit link
>> >> >> -one of the devices may be a PC with AV features
>> >> >> -3 AV applications are fighting to use the link at the same time
>> >> >> 1. uncompressed mutli-channel audio (as RTP streams)
>> from A to B
>> >> >> (needs ~50Mbps)
>> >> >> 2. compressed HDTV stream via HTTP from A to B (needs
>> ~25Mbps with
>> >> >> overhead)
>> >> >> 3. HTTP file copy for immediate viewing from A to B
>> (file is 20GB
>> >> >> video file)
>> >> >> -packets go over the link on first-come, first-serve basis
>> >> >> -application #3 decides to burst the copy at max speed
>> >> >> -the fat pipe is now very unusable for AV applications #1 and #2
>> >> >>
>> >> >> -John Gildred
>> >> >> Vice President of Engineering
>> >> >> Pioneer Research Center USA
>> >> >> A Division of Pioneer Electronics
>> >> >> 101 Metro Drive, Suite 264
>> >> >> San Jose, California 95110
>> >> >> john@pioneer-pra.com
>> >> >> (408) 437-1800 x105
>> >> >> (408) 437-1717 Fax
>> >> >> (510) 295-7770 Mobile
>> >> >>
>> >> >> On Aug 31, 2004, at 8:49 PM, Gross, Kevin wrote:
>> >> >>
>> >> >> > I've been doing a bit of prodding on point 1 here. No
>> response yet.
>> >> >> >
>> >> >> > On point 2 I would be happy if we could start by
>> identifying a use
>> >> >> > case that
>> >> >> > cannot be addressed through modest overprovisioning.
>> >> >> >
>> >> >> > As for connection based IP QoS, I see how that is useful
>> >> getting _to_
>> >> >> > the
>> >> >> > home, but I don't expect to see that deployed _in_ the home.
>> >> >> >
>> >> >> > -----Original Message-----
>> >> >> > From: owner-stds-802-3-re@listserv.ieee.org
>> >> >> > [mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf Of Henry
>> >> >> > Sariowan
>> >> >> > Sent: Tuesday, August 31, 2004 6:23 PM
>> >> >> > To: STDS-802-3-RE@listserv.ieee.org
>> >> >> > Subject: Re: [RE] CE applications (was: RE: [RE] Focus of
>> >> discussions)
>> >> >> >
>> >> >> > Having followed the ongoing discussion, this group needs to
>> >> have solid
>> >> >> > answers for the following issues:
>> >> >> >
>> >> >> > 1. Comprehensive list of all LEGITIMATE use cases for Residential
>> >> >> > Ethernet
>> >> >> >
>> >> >> > 2. Technical and business reasons why some, if not all,
>> of the use
>> >> >> > cases
>> >> >> > cannot be addressed by the existing QoS solutions
>> >> >> >
>> >> >> > 3. All fundamental characteristics of the Residential
>> Ethernet that
>> >> >> are
>> >> >> > required to address the use cases
>> >> >> >
>> >> >> > And I think, some of these fundamental RE characteristics
>> >> that cannot
>> >> >> > be
>> >> >> > addressed by existing IP-based QOS (consisting of a
>> combination of
>> >> >> > admission control/traffic shaping, QoS scheduling (such
>> as WFQ), and
>> >> >> > reservation signaling) should include at least:
>> >> >> > - (virtually) CONSTANT, SUB-MILLISECOND latency for the
>> >> >> > real-time traffic
>> >> >> > - (virtually) ZERO/SUB-FRAME jitter for the
>> >> real-time traffic
>> >> >> > - (virtually) ZERO packet loss for the real-time traffic
>> >> >> > - SIMPLE bandwidth/connection reservation scheme
>> >> >> >
>> >> >> > IMHO, by clearly highlighting the technical requirement
>> >> that cannot be
>> >> >> > addressed by the existing QoS solutions, people can
>> start seeing the
>> >> >> > need for an alternative solution.
>> >> >> >
>> >> >> > Henry
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > -----Original Message-----
>> >> >> > From: owner-stds-802-3-re@listserv.ieee.org
>> >> >> > [mailto:owner-stds-802-3-re@listserv.ieee.org] On Behalf
>> Of Richard
>> >> >> > Brand
>> >> >> > Sent: Tuesday, August 31, 2004 3:56 PM
>> >> >> > To: STDS-802-3-RE@listserv.ieee.org
>> >> >> > Subject: Re: [RE] CE applications (was: RE: [RE] Focus of
>> >> discussions)
>> >> >> >
>> >> >> > Kevin:
>> >> >> > Ask the Consumer Electronics Association if Dolby 5.1 ==>
>> >> Dolby 6.0 is
>> >> >> > selling well. Take a listen sometime.
>> >> >> > Also, remember that we in the tech industry are atypical
>> of most of
>> >> >> the
>> >> >> > consumer product customer base.
>> >> >> > I'd recommend that you book your rooms in Vegas now for
>> the Consumer
>> >> >> > Electronics show in Jan. to understand this industry (why
>> >> we called it
>> >> >> > "Residential Ethernet"). You cannot assess unless you can
>> >> experience
>> >> >> > it. FYI attendance at the CEA show has far surpassed
>> the attendance
>> >> >> of
>> >> >> > any of our technology or computer/communications trade
>> >> shows. Been to
>> >> >> > Comdex lately?
>> >> >> > Richard
>> >> >> >
>> >> >> > "Gross, Kevin" wrote:
>> >> >> >
>> >> >> >> I don't work day-to-day in consumer applications but I haven't
>> >> >> >> recently seen that sector make many successful
>> decisions that favor
>> >> >> >> fidelity over functionality.
>> >> >> >>
>> >> >> >> The recent successes in the consumer electronics market have all
>> >> >> >> introduced new functionality (sometimes paired with increased
>> >> >> >> fidelity) - DVD, Direct satellite, MP3, TiVO.
>> >> >> >>
>> >> >> >> Advances that focus on improved fidelity have not
>> faired as well -
>> >> >> >> Super audio CD, DVD Audio, High-definition TV.
>> >> >> >>
>> >> >> >> -----Original Message-----
>> >> >> >> From: owner-stds-802-3-re@listserv.ieee.org
>> >> >> >> [mailto:owner-stds-802-3-re@listserv.ieee.org] On
>> Behalf Of Dennis
>> >> >> Lou
>> >> >> >> Sent: Tuesday, August 31, 2004 12:53 PM
>> >> >> >> To: STDS-802-3-RE@listserv.ieee.org
>> >> >> >> Subject: Re: [RE] CE applications (was: RE: [RE] Focus of
>> >> >> discussions)
>> >> >> >>
>> >> >> >> On Tue, 2004-08-31 at 11:24, Dirceu Cavendish wrote:
>> >> >> >>> <DC> I guess anything with less quality than what current CE AV
>> >> >> >>> equipment provides is unacceptable. Am I wrong? Or
>> would we follow
>> >> >> >>> the VoIP trend of replacing high quality voice calls with
>> >> something
>> >> >> >>> of less quality? Over to CE guys...
>> >> >> >>> </DC>
>> >> >> >>
>> >> >> >> I would tend to agree. The only thing I would add is that for
>> >> >> >> consumer grade equipment, perceived quality (as measured
>> >> by a typical
>> >> >> >> ear/eye vs. a spec sheet) must not be less than current
>> >> equipment and
>> >> >> >> any quality degradation must be offset by other
>> beneficial factors
>> >> >> >> (convenience, cost, etc). Examples are MP3 vs. CD, JPEG
>> >> vs. lossless
>> >> >> >> compression, etc.
>> >> >> >>
>> >> >> >> -Dennis
>> >> >>
>> >>