[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
>> >>
>>