Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [RE] CE applications (was: RE: [RE] Focus of discussions)



Kevin;

I wish you were on the Residential Ethernet CFI and our other face-to-face
meetings. I guess the garage band live performance is an example of when
overprovisioning does not practically guarantee the acceptable performance.
As the CobraNet developer you certainly learned the limitations that we
inherit with existing layer 2 and the possible impact of unexpected
connection of an "alien" computer to an Ethernet based digital audio
network. Isn't it time to address it?
Best regards,

Alexei Beliaev
408-313-2665


----- Original Message -----
From: "Gross, Kevin" <kevin.gross@CIRRUS.COM>
To: <STDS-802-3-RE@listserv.ieee.org>
Sent: Thursday, September 02, 2004 8:18 AM
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
> >>