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