Re: [RE] What's wrong using FireWire as the home backbone?
I am familiar with the Gibson Ethernet guitar. Can someone please fill me in
on the Pioneer application?
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG] On
Behalf Of Dirceu Cavendish
Sent: Friday, September 03, 2004 1:09 PM
To: STDS-802-3-RE@listserv.ieee.org
Subject: Re: [RE] What's wrong using FireWire as the home backbone?
<DC>
I guess we need to discuss first what exactly needs to be accomplished
by this SG. The PAR criteria seem to be a consensus, but HOW to achieve
it is another matter. In my mind, we should try to accomplish it with
the minimum amount of work from the participants - hence, visiting every
single OSI layer vis-à-vis CE requirements, as stated below, does not
seem to me to be the way, although I do acknowledge it would be the most
comprehensive.
I believe the most straightforward way is to focus on a given CE
application (S), and clearly show problems arising from the usage of
current Ethernet .3 links. We could lock into Gibson's Ethernet guitar
application, or Pioneer audio device, whatever people feel easier to
tackle. I am sure Gibson and Pioneer have done various "Ethernet trials"
on their applications, so sharing results with the SG could be the
quickest way to address the 5 item criteria...
</DC>
Dirceu Cavendish
NEC Labs America
10080 North Wolfe Road Suite SW3-350
Cupertino, CA 95014
Tel: 408-863-6041 Fax: 408-863-6099
-----Original Message-----
From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-re@IEEE.ORG]
On Behalf Of Hugh Barrass
Sent: Friday, September 03, 2004 6:46 AM
To: STDS-802-3-RE@listserv.ieee.org
Subject: 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".
>
>
>
>