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

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.
>>
>>
>