Re: [RE] Grand master identifier
My comment A should refer to requirement #1, not #2.
John Gildred
Pioneer Electronics
On May 5, 2005, at 11:45 PM, 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.
>
> John Gildred
> Pioneer Electronics
>
> On May 5, 2005, at 2:53 PM, Hugh Barrass wrote:
>
>
>> Arthur,
>>
>> It is definitely the case that many things become easy with over
>> provisioning and simple QOS. However, the term "over provisioning"
>> has two key elements: "over" implies that you must set a level of
>> usage that is not exceeded. This may be 75% of link b/w as has
>> been suggested, it may be lower to enable better statistical
>> behavior. In any case, there is a level at which "over" is no
>> longer satisfied. Secondly there is "provisioning." There needs to
>> be a mechanism to guarantee that the QOS will work as required.
>> This generally takes the form of admission control and/or policing.
>>
>> Personally, I believe that the existing standards for
>> provisioning, admission control, policing and QOS could be
>> implemented easily and cheaply in a residential environment. If
>> this is not the case, then proof should be presented to make a
>> case for new standards. Either way, I think there is a need for
>> some architectural specification to ensure that RE products have
>> appropriate capabilities to allow plug in and go operation.
>>
>> Hugh. < speaking strictly for myself >
>>
>> Arthur Marris wrote:
>>
>>
>>
>>> David,
>>> I am not an STP expert but my understanding is that spanning
>>> tree is
>>> used by bridges to find out which of their ports are connected to
>>> other
>>> bridges. The protocol then determines a root bridge and shuts down
>>> redundant links to make sure there are no network loops. As I
>>> understand
>>> it the MAC address is for the bridge rather than the end station. I
>>> don't think the end stations are involved in STP.
>>>
>>> I am not sure whether you are inviting general feedback on your
>>> working paper but I have some concerns. It assumes that there
>>> will be
>>> access control, bandwidth allocation and time slots for
>>> transmission.
>>>
>>> Is bandwidth allocation really necessary to meet RE requirements?
>>> Over-provisioning and best-effort (with class of service) may be
>>> adequate. You can get a lot of data through a conventional gigabit
>>> switch with very low latencies. The RE traffic can be given a higher
>>> priority and so not be held up by less urgent traffic.
>>>
>>> With access control what happens if access is denied? My
>>> assumption
>>> is that a user connecting to a RE network would prefer best-effort
>>> service to no service at all if there is no spare bandwidth to be
>>> allocated. If you decide you need to support best-effort as a
>>> fallback
>>> then you need buffers in your end stations and the reason for
>>> using time
>>> slots goes away.
>>>
>>> Arthur.
>>>
>>> -----Original Message-----
>>> From: owner-stds-802-3-re@IEEE.ORG [mailto:owner-stds-802-3-
>>> re@IEEE.ORG]
>>> On Behalf Of David V James
>>> Sent: 29 April 2005 22:20
>>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>>> Subject: [RE] Grand master identifier
>>>
>>> All,
>>>
>>> I was starting to update a group-contribution working paper,
>>> when a couple of questions arose. For reference, these questions
>>> are with respect to:
>>> http://www.ieee802.org/3/re_study/material/index.html
>>> Subclause 5.2.
>>>
>>> We assume that the grand master is selected by picking one
>>> of the clock-master capable stations. To do this, IDs need
>>> to be distributed externally (between bridges and stations)
>>> as well as internally (between bridge ports).
>>>
>>> To avoid invention, we assume the existing STP identifier
>>> format should be used (why be different?). The format, not
>>> the actual values; an grand master could be different from
>>> the STP root.
>>>
>>> My original assumption was that the precedence value,
>>> transmitted between stations, consists of:
>>> 16 bits -- system
>>> 48 bits -- MAC address
>>> 16 bits -- port
>>>
>>> Having started to write things in more detail, it seems
>>> like the port information need only be used within a
>>> bridge, and need never appear on Ethernet.
>>>
>>> Pardon my asking, but the appropriate 802.1 documents are
>>> not that easy for me to read. Am I correct in my recent
>>> thoughts, that the port portion of this identifier is
>>> only used within the bridge, and never appears on the outside?
>>>
>>> DVJ
>>>
>>>
>>>
>>
>