Re: [RE] Grand master identifier ==>(evolved to) overprovisioning
Hugh,
Thanks for insightful throughs. We certainly agree on
plug-and-go/plug-and-play(:>), as opposed to plug-and-pray(:<).
>> Personally, I believe that the existing standards for provisioning,
>> admission control, policing and QOS could be implemented easily and
>> cheaply in a residential environment.
Which ones, in particular, and how would they be used?
Its hard to test such an hypothesis, without reference material
and assumptions.
>> If this is not the case, then proof should be presented to make
>> a case for new standards.
Assuming 75% time-sensitive traffic with arbitrary topology
and loading (subject the the aforementioned 75% rule), then
I believe proofs are contained within "Annex G" of:
http://www.ieee802.org3/re_study/material/index.html
>> 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.
Agreed! Although some of us use the term plug-and-play.
I assume (correct me if not) that these mean the same thing.
DVJ
David V. James
3180 South Ct
Palo Alto, CA 94306
Home: +1.650.494.0926
+1.650.856.9801
Cell: +1.650.954.6906
Fax: +1.360.242.5508
Base: dvj@alum.mit.edu
>> -----Original Message-----
>> From: owner-stds-802-3-re@IEEE.ORG
>> [mailto:owner-stds-802-3-re@IEEE.ORG]On Behalf Of Hugh Barrass
>> Sent: Thursday, May 05, 2005 1:54 PM
>> To: STDS-802-3-RE@LISTSERV.IEEE.ORG
>> Subject: Re: [RE] Grand master identifier
>>
>>
>> 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
>> >
>> >
>> >
>>