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

Re: [RE] Network topology requirements (was: [RE] CE applications )



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