Re: [RE] What's wrong using FireWire as the home backbone?
Hi John,
I just wanted to comment on your statements 'this group is tasked with producing
an enhancement to 802.3' and 'This project is about making Ethernet an option
for such applications.' that you made in your e-mail. In IEEE-SA terms, this is
not yet a project, a project requires a Project Authorisation Request (PAR)
approved by the IEEE-SA Standards Board. This instead is a IEEE 802.3 Study
Group.
Regardless of terminology I just wanted to clarify the following. The task of
this Study Group is to achieve consensus on a draft PAR and five criteria then
gain approval for them from the IEEE 802.3 Working Group, the Sponsor and then
the IEEE-SA. In addition it is normal practice, and in my opinion essential in
gaining IEEE 802.3 approval, for a set of objectives for the project to be also
generated. Only if there is an approved PAR for an IEEE 802.3 amendment will
there be a project that is tasked with making enhancements to IEEE 802.3.
You may wish to review the IEEE 802.3 Rules in respect to IEEE 802.3 Study
Groups in more detail [ http://www.ieee802.org/3/rules/P802_3_rules.pdf#Page=12
] however I have reproduced what I thought was the most relevant portion below.
I hope this helps.
Best regards,
David Law
4. 802.3 Study Groups
4.1 Function
The function of a Study Group is to complete a defined task with specific output
and in a specific time frame established within which they are allowed to study
the subject. Once this task is complete the function of the SG is complete and
its charter expires.
The normal function of a 802.3 Study Group (SG) is to draft a complete PAR and
five criteria (see 7.2) and to gain approval for them at WG 802.3, 802 EC, IEEE
New Standards Committee (NesCom) and the IEEE Standards Board. The decision of
whether to utilize the 802.3 WG, or to establish a new WG or Technical Advisory
Group (TAG) to carry out work items recommended by a SG is be made by the EC
with due consideration of advice from the 802.3 WG.
John Grant <j@NINETILES.COM>@IEEE.ORG on 03/09/2004 10:58:56
Please respond to "IEEE 802.3 Residential Ethernet"<stds-802-3-re@IEEE.ORG>
Sent by: owner-stds-802-3-re@IEEE.ORG
To: STDS-802-3-RE@LISTSERV.IEEE.ORG
cc:
Subject: 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