Re: [RE] What's wrong using FireWire as the home backbone?
John,
I think that David has already pointed out that the group has not yet
been tasked with producing a standard. First it must study the problem
to see if a change to the standard is required. When deciding whether a
new project would meet the 5 criteria required, we should consider
whether it's an area covered by other standards, whether it's broadly
compatible with what we currently have, and whether it's liable to
generate the revenues to justify the significant work of making the new
standard and then developing products to support it.
It is not a given that Ethernet must solve every problem there is.
There are many standards in the world. Some overlap, some are regional,
my favorites are international and globally accepted (such as the metric
system or GSM :-). There is no need for Ethernet to define a new way of
solving a problem that is adequately solved by another standard. I
believe that we need to show both the deficiencies of the existing
standard (or the lack of a standard) as well as the deficiencies of
Ethernet to be addressed in order to show that a project would be justified.
Furthermore, you rightly point to the OSI stack diagram to show how
Ethernet (or any other link/PHY layer) does not give a service to the
user. However, I disagree that we should start at the bottom to rewrite
the standards. I believe that we (or someone interested the the "QoE")
should start at the top. To improve the user experience of a networked
home, the first thing to address might be the multiplicity of audio and
video standards. This could be followed very rapidly by the multiplicity
of user interfaces and remote access methods. These are the biggest
barriers to to most users enjoying a "connected experience" at home.
Further down the stack you will run into inappropriate or
inappropriately used transport protocols that fail to take account of
the problems being addressed. This would include failure of most
transport layer interfaces to use even the most trivial of
prioritization. There are also some missing protocols that would solve
some of the more pressing issues - such as a loop timing based
synchronization protocol that would allow multiple devices to lock their
clocks to within 100uS across a network with latency variation in the
0-10mS range.
After you have resolved the higher layer problems - especially at the
application layer - then you define the requirements for the link and
physical layer solutions. It may be that you will see FireWire as the
ideal candidate. In which case it would be pointless to simply change
Ethernet to resemble FireWire. If neither Ethernet nor FireWire will
meet the requirements of a layer 7 through 3 solution then you should
examine which one will require the least modification to fulfill the
job. Again, changing Ethernet to look like a slightly modified FireWire
should not be an option.
Making changes to a standard costs millions of dollars - just in the
time, travel and opportunity cost of hundreds of engineers making sure
that they get it right. Implementing those changes onto a new range of
products will cost hundreds of millions or billions of dollars
industry-wide. It is far better to re-use existing standards where
possible. I, for one, would like to see some proof that serious attempts
have been made to fix the problems in layers 3-7 for home networking
applications before I agree that we need to make significant changes to
layer 1 or 2.
Hugh.
John Grant wrote:
>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".
>
>
>
>