Re: [RE] Resume (was: Network topology requirements (was: [RE] CE app lications ))
I have invented and implemented real-time audio over Ethernet networking
called CobraNet. We have technical and marketing details on our website -
www.peakaudio.com. Cirrus Logic acquired us in 2001.
CobraNet is deployed in commercial and professional applications. I have
helped design and commission some of the more advanced installations (i.e.
Tokyo Disney Sea theme park) and so gained first-hand experience of what
networks can do and how to do it.
In our lab we are continually evaluating new network gear for CobraNet
installations. We've played with stuff all the way from refrigerator sized
core switches to 4-port switches borrowed from the shelves of CompUSA. We've
recently begun incorporating power over Ethernet into some installations.
My consumer chops come from my involvement with the Cirrus mother ship these
past 3-4 years. As a major parts supplier to CE companies, we have direct
insight into what CE products and technologies are in development, what is
catching on and what is floundering.
Earlier in my career I worked in video. I have standards experience in the
Audio Engineeing Society.
My participation in Residential Ethernet began with meetings I had with
Gibson last year. I'd like to contribute my knowledge of networking
capabilities and media requirements. I'd like to identify emerging
applications for real-time media networks. I have designed, implemented and
deployed media protocols, so when it comes to engineering, I would hope to
be useful.
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On
Behalf Of Richard Brand
Sent: Thursday, September 02, 2004 12:13 AM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] Network topology requirements (was: [RE] CE applications )
Kevin:
Because I welcome your input and so I can respond to you efficiently I am
trying to
determine how much of the CEA applications and environment and therefore the
related
acronyms with which you may be familiar. This may seem self serving but
since I have put
my reputation on the line in July in bringing this issue successfully in
front of 802.3, I
think I have earned the right to question those who may question the
objectives of this
Study Group without a full understanding of the new CE apps (see the CFI).
I did check
with Google to learn about Cirrus and did find a link for Cirrus Networks
which is well
connected with the works of CEA and the UPnP work. Is that your connection
or are you
strictly an independent and therefore I should expect to provide you with
full consumer
related Residential Ethernet details. Since we choose to name this work
effort
Residential Ethernet we welcome those who understand the rigors and QoS
requirements of
consumer multimedia delivery in a worst case network environment otherwise
known as the
residence.
Kevin, let me know your level of knowledge about multimedia content
transport in this (the
residential) environment.
So that all of you on this reflector know who I am, I have been studying
consumer
requirements and have been a recent participant of the DLNA (everybody now
knows what this
is right?) content delivery on home/residential networks for over 1 year.
I have also
been active in the 802.3 the "Ethernet" standards works since the days of
"Cheapernet" or
the early '80s and know that our focus in 802.3 has been overwhelmingly on
data only
applications. ATT was active in the late 80's but never for MM apps. John
Grant brought
up the 802.9a work and I am the person who introduced this effort into 802
and was the
liaison from 802.9 to 802.3. A rep from ATT was active in this work. That
was a painful
experience for me not because of the technology but because of my then
employer's roll
over position. Michael Jonas Tener was also incidentally involved as my CEO
went over to
become his CEO.
I also was the liaison to 802.1 for 802.9 in the 90's before I went out to
do the start up
thing and am now the liaison from 802.3 to 802.1 and am knowledgeable of
those
discussions that occurred in the '90's (very much of a compromise but fully
focused on the
enterprise) and was the CoB and President of the Multi Media Communication
Forum for two
years in the mid 90's and provided liaison to the IMTC. Add to that that I
worked on the
ITU H.32X ITU multimedia over LANS documents and am following the further
ITU work on
video quality as a part of the Video Quality Experts Group VQEG which will
soon dive into
the ATSC based HDTV issues. I have also learned that my colleagues from
Nortel including
Tim who I have learned is one of the prime authors of the ITU G.1010
multimedia apps
document.
Not to be self focused but I am proud to say that I have put in a lot of my
personal time
on solving this MM (real time video voice) transport quality issue. That is
probably too
much about me, but I will say that the what I will call patches to 802.3 via
802.1 efforts
still do not provide the level of quality (QoE) that consumers expect on a 5
X 9 basis
because they have no time for failures.
Kevin, pls advise your experience with these consumer applications that we
detailed in the
CFI so that I can address your comments accordingly. This is a greenfield
for 802.3 and
therefore we cannot use enterprise efforts which may or may not have been
successful.
My commitment to this SG effort is to provide some consumer applications
data at L2 or
below for real time voice/video applications. FYI, the model for HD (ATSC
High Definition
TV) is just now being defined in an ITU-T offshoot group connected with the
National
Bureau of Standard (NTIA group).
Comments,
Richard
"Gross, Kevin" wrote:
> Q: Which is most acceptable to the homeowner...
> a/ Reworking their network topology or...
> b/ Replacing network equipment with media-aware variants?
>
> A: None of the above :)
>
> As far as real-time performance is concerned, it is not the total number
of
> bridges that is at issue but the number you have in your longest series
path
> through the network. This is often referred to as network diameter. In
> CobraNet installations we recommend a network diameter no greater than 5
> 100Mbit switch-hops.
>
> I would propose that limiting residential Ethernet diameter to 2 100Mbit
> hops + 2 Gbit hops as a reasonable restriction. This would give you a
> forwarding delay + delay variation performance less than 1ms. Assuming
> you're using Gbit uplinks everywhere (as per overprovisioning), you'd have
> to work hard to exceed these limits in a home installation.
>
> -----Original Message-----
> From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On
> Behalf Of Michael D. Johas Teener
> Sent: Wednesday, September 01, 2004 1:00 PM
> To: STDS-802-3-RE@listserv.ieee.org
> Subject: Re: [RE] Network topology requirements (was: [RE] CE
applications)
>
> Now we are getting to something that we need to discuss in some detail and
> come to a reasonable consensus: limits on topology ...
>
> My home (which is not a particularly high-tech example), has one 10/100
> bridge/router/firewall, one 802.11b AP (a type of "bridge"), and one
802.11g
> AP. This is all just to support the three PowerBooks and one iMac in the
> family. If I wanted to put the four televisions, three VCRs, two DVD
> players, two audio receivers and two CD players on the wired net, I think
> I'd need a bridge in each room that has A/V gear (four rooms, but one
> already has a bridge, so that's only three more). The various boom boxes
and
> iPods/MP3 players will connect to the existing wireless infrastructure (or
> some sort of 802.11e-enabled follow-on). Then there's the horrible analog
> video monitoring/security system we have ... That should be one the wired
> net as well.
>
> The DTV/audio "clusters" will likely be connected together with 1394, but
> the bridges between 1394 and 802.3+ will have queues as well, so that
> doesn't reduce the need for queue management.
>
> Hmm. Lots of gear there. I think this means we will have lots of bridges.
>
> So, rather than imposing a new limit that doesn't currently exist in the
802
> universe, shall we say:
>
> ---
>
> The new services can work in any system of bridged 802 networks that
support
> isochronous transport (this means 802.11e in the 802.11 universe,
802.15.3a
> [probably, depending on religious battles over there], and the enhanced
form
> of 802.3 we are talking about. Note that the new services will work much
> better in 802.3 because the link QoS is so good.
>
> The 802.3 restriction would be that it would *only* work on full duplex
> links. No repeaters, no old coax systems.
>
> ---
>
> Note that I think this is perfectly reasonable, and, indeed, a
requirement.
> Imposing limits beyond "a bridged network" is asking for trouble, in my
> opinion ... I'm willing to ask the consumer to buy a "CEthernet" (or some
> other brands/labels/tags) device to get the services they want, but I'm
not
> willing to ask them to unreasonably limit the number or topology of those
> devices.
>
> Finally ... It is my opinion (and just my opinion), that a very low
latency,
> highly "synchronous", user-friendly (QoE?) system can be built for very
low
> cost. This would involve no changes to the 802.3 PHYs or MAC, but would be
a
> sublayer between the MAC and LLC (like MAC services .. Maybe an
enhancement
> to MAC services). It would also be best if some changes to 802.1Q were
> involved so that the isochronous services could pass between 802.3 and
> 802.11/802.15.3.
>
> On 9/1/04 10:16 AM, "Gross, Kevin" <kevin.gross@CIRRUS.COM> wrote:
>
> > Michael, I think you are correct also. Additional forwarding hops
requires
> > additional buffering.
> >
> > The next question is, is this a practical consideration for the home
where
> > we might assume a limited number of hops and relatively relaxed latency
> > requirements?
> >
> > -----Original Message-----
> > From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
> On
> > Behalf Of Michael D. Johas Teener
> > Sent: Wednesday, September 01, 2004 10:43 AM
> > To: STDS-802-3-RE@listserv.ieee.org
> > Subject: Re: [RE] CE applications (was: RE: [RE] Focus of discussions)
> >
> > I think you are correct, Kevin, with one major concern: using strict
> > priority mechanisms through multiple queues (transmitter, bridge, [more
> > bridges/routers], receiver), the high priority packets tend to bunch up
> and
> > arrive in bursts that will require bigger buffers at the receiver.
> >
> > There are simple fixes to all this however, providing that there is a
> > "network"-wide synchronization mechanism. (where "network" means the
cloud
> > of interconnected devices that can share the synchronization method.)
> >
> > On 9/1/04 8:54 AM, "Gross, Kevin" <kevin.gross@CIRRUS.COM> wrote:
> >
> >> Isn't this scenario addressed by 802.1Q? 802.1Q is implemented in
> switches
> >> but also in the network stacks of end stations. The file copy would be
> >> assigned a lower priority and the network stack in device A would
> > recognize
> >> this and queue packets for transmission from the streams ahead of the
> file
> >> copy transmissions.
> >
> > --
> > -----------------------------------------------------------
> > Michael D. Johas Teener - Mike@Teener.com PGP ID 0x3179D202
> > 23 Acacia Way, Santa Cruz, CA 95062-1313
> > +1-831-247-9666, fax +1-831-480-5845
> > ------------------- www.teener.com ------------------------
> >
>
> --
> -----------------------------------------------------------
> Michael D. Johas Teener - Mike@Teener.com PGP ID 0x3179D202
> 23 Acacia Way, Santa Cruz, CA 95062-1313
> +1-831-247-9666, fax +1-831-480-5845
> ------------------- www.teener.com ------------------------