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

Re: [RE] What's wrong using FireWire as the home backbone?



At 11:28 02/09/2004 -0700, Hugh Barrass wrote:
>David,
>
>When you ask the question, "Wouldn't you prefer to be on top?" you seem
>to be equating people (or possibly companies) with standards. That is
>illogical. A person (or company) capable of building an 802.3 network
>should also be capable of building a 1394 network.

I agree that the sentiments implied by that question are inappropriate; I, for one, have no historical or emotional attachment to any of the IEEE802 standards and simply regard the 802.3 PHY layers as being a good solution to the problem of moving bits and bytes from A to B, given all the engineering considerations of cost, performance, availability, etc.

However, this group is tasked with producing an enhancement to 802.3 so saying "use FireWire instead of 802.3" is not helpful at this stage.

We have been talking a lot about the user, but if you look at, say, figure 22-1 of 802.3-2002 you will see that 802.3 doesn't provide a service to the user, it provides a service to the network layer, which in turn provides a service to the transport layer, and so on all the way up to the application layer which is the one that actually provides a service to the user.

The question we are addressing is whether the service currently offered by 802.3 is adequate for the kind of middle layers that are required to support CE applications, and, if not, what can be done to fix it.

The answer seems to be that it falls short in the areas of (1) providing a timing reference and (2) providing the kind of guaranteed bandwidth that allows low enough latency (which implies minimal buffering) without clicks and pops severe enough that even ordinary users will be annoyed by them happening when there are bursts of other traffic (and here I agree that just because PCs are inefficient enough, and TCP polite enough, not to saturate the network we can't assume that some ruder devices that can transfer files at wire speed won't come along when it's too late to do anything about it).

So what actually needs to be done is not to re-engineer the whole stack, starting from the bottom (which has been done often enough before, and usually seems to run out of steam halfway up) but to look at the network layers that can do the business, and provide the services they need. Note that we aren't necessarily looking for a single network layer that will do everything, but to support any network layer that is used for any of the applications we are considering.

The original proposal carried a number of "slots" repeated every 125 usec, which would satisfy (1) if the timing can be made accurate enough (how accurate is "enough"?), and should also satisfy (2) if the protocols for allocating the slots are well-enough behaved. It was not clear to me how big a "slot" is. If it is 32 bits, I think this provides the service needed by 1394 (to convey a quadlet every 125 usec), though I am rather hazy on the details of 1394. It could also be subdivided into four ISDN channels, and should also, I think, be suitable for other formats such as BlueTooth.

My own current interest is chiefly in the carriage of 52-octet (NB not 53) ATM cells for AES47 <http://www.aes.org/standards/b_pub/aes-standards-in-print.cfm#AES47>; cells carrying audio and video could have space reserved for them after the 32-bit slots, before the "normal" Ethernet packets.

AES Project X143 (see http://www.aes.org/standards/b_policies/project-status.cfm near the end of the page; see the top of the same page for how to join the Task Group) is looking at AES47 over Ethernet PHY; currently only dedicated point-to-point links provide the necessary QoS but a Residential Ethernet standard could allow it to share networks with traditional (shall I call it "legacy"?) Ethernet traffic.

I realise that AES47, which is comparatively new, is currently only used in radio broadcasting but it may well spread to CE in the future. Incidentally, what was the rationale for the change from "synchronous Ethernet" (supporting any applications that have requirements for timeliness) to "residential Ethernet" (specifically targetted at CE applications)?



[snip]

>What is missing from FireWire that prevents it from solving the problems
>of wired home networking?

Maybe some of the higher layers that would make it a complete system rather than just an interconnect, maybe nothing, but that isn't really the point.

As of now, Ethernet (taking this to include MAC layer, bridges, switches etc, not just the PHY layer) can't carry real-time media streams, the best it can do is transfer files that can be played out locally, though in favourable circumstances that can be done slickly enough that it appears almost the same to the user.

So for any application that requires timeliness Ethernet isn't an option, though 1394 proably is. This project is about making Ethernet an option for such applications.

Note that 6.3(a) in Policies and Procedures says "Substantially different from other IEEE 802 standards", not "... from all other IEEE standards".


John Grant
   ___  ___  ___  ___    ___  ___  ___  ___  ___
  |   ||   ||   ||   |  |   ||   ||   ||   ||   |
  | N || i || n || e |  | T || i || l || e || s |
  |___||___||___||___|  |___||___||___||___||___|

Nine Tiles Networks Ltd, Cambridge, England
+44 1223 862599 and +44 1223 511455
http://www.ninetiles.com