Re: [RE] Resume (was: Network topology requirements (was: [RE] CE app lications ))
I think Tokyo Disney Sea is a good example of the difference between
managed and unmanaged systems. I assume that the visitors of Disney Sea
did not select, purchase and install the CobraNet system.
That is the home in a nutshell. The average consumer is expected to
know nothing about their home network system. It should be plug and
play, no configuration, no administration.
So this brings up the the idea of using categorized priorities with
admission control. I believe such a solution would be expensive,
cumbersome and likely unacceptable to the consumer.
-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 Sep 2, 2004, at 7:35 AM, Gross, Kevin wrote:
> 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 ------------------------