Re: [RE] Grand master identifier
I would not assume the existence of specific higher layer protocols
(IP and above) in every case. Furthermore, the ability to cost reduce
such higher layer intelligence is much less than at the MAC level (or
very close to it). The higher up you go in the stack, the more we
want to customize the implementation. For example there is RSVP and
UPnP QoS, both run over IP, and both try to address the RE problem.
Neither of them are low cost solutions to a very straight forward
problem. Most implementers of such higher layer protocols in embedded
products are not using cheap ASICs, their using fairly fast CPUs
(ARM9, MIPS R5, etc.) as they want to keep the higher layer protocol
implementations in an easily changeable form (C/C++ code). This is
how it's done in digital TVs, DVD recorders, and the like. We expect
to see the RE functionality to be built into an Ethernet core at no
incremental cost in the near future.
What I don't want to see is the CE industry going off and creating an
"enhancement" to the 802.3 MAC which is defined outside of IEEE and
becomes a defacto CE industry standard to satisfy our product
requirements. That is what I would like to avoid. I think that there
is enough general usefulness in RE for other industries that it
should not be done in an industry specific way.
My .02
John Gildred
Vice President of Engineering
Pioneer Research Center USA, Inc.
a Division of Pioneer Electronics
408-437-1800 Office
408-437-1717 Fax
510-295-7770 Mobile
john@pioneer-pra.com E-Mail
AIM:johntgildred
On May 6, 2005, at 7:22 AM, Hugh Barrass wrote:
> John,
>
> It depends on how you measure cost.
>
> I assume that any RE device will support IP- in fact, I would
> recommend against any networked device ignoring that requirement.
> This means that the devices will also support DHCP and DNS.
> Furthermore I would recommend that most devices will also support
> either TCP or UDP and that any key device will support HTTP. Given
> those assumptions, incremental requirement to support RSVP will be
> no more than 10's of kbytes of codespace. A reasonably implemented
> and appropriately scaled device (whether end station or hub) should
> be able to support a standard method for provisioning at NO
> INCREMENTAL COST. I would like to see an analysis disproving this
> that also demonstrates why a new standard would not incur
> equivalent overheads. Remember that the argument that nobody builds
> it today is equally applicable to anything new that is proposed.
>
> Regarding your comments - it is absolutely true that no mechanism
> exists in 802.3 for either of those requirements. This is because
> both of those requirements are met (or otherwise) by the bridge and
> the system behavior. Nothing in the definition of a PHY or a
> fullduplex MAC will help to meet those requirements (with the
> exception of PHY latency that is under discussion in 10GBASE-T). It
> is entirely specious to suggest that anything defined at a higher
> layer (than 802.3) will be too expensive or not interoperable.
> There are many things that are very cheap indeed and interoperate
> perfectly that are not defined by 802.3 - although I would
> recommend against any physical layer network interface defined by
> anyone else :-)
>
> Hugh (speaking for myself, and not representative of the views of
> ITU-T :-)
>
> John Gildred wrote:
>
>
>> Hi Hugh:
>>
>> I am not aware of any low cost standardized methods for
>> provisioning, admission control, policing and QoS which work
>> together to satisfy the requirements of RE. The consumer
>> electronics definition of low cost is NO INCREMENTAL COST.
>>
>> My understanding of the 2 most basic RE requirements:
>> 1. We need a low cost way to ensure that the traffic for one
>> application does not interfere with the timely delivery of all
>> traffic for another application.
>> 2. We need a low cost way to ensure a very low max latency (250
>> usec per hop) for all traffic of a specific application.
>>
>> My comments on current mechanisms for this in 802.3:
>> A. There is no mechanism in 802.3 to ensure requirement #2 will
>> be met in every case, across various implementations.
>> -Overprovisioning cannot provide such a guarantee as more
>> applications are added to the network.
>> -There is no admission control system for 802.1D
>> priorities. Of course, higher layer protocols (Layer 3+) could
>> be used for admission control, but at considerable cost and added
>> risk to interoperability.
>> B. There is no mechanism in 802.3 to ensure requirement #2 will
>> be met in every case, across various implementations.
>>
>>
>