Re: [RE] Categories of RE development
Bill,
Thanks for the interesting comments.
Some (hopefully) responsive comments interleaved.
>> A) Vocabulary. A few commonly used terms.
>> 1) What should we call a sender of isochronous data?
>> [WMS] * other _source___________
>> 2) What should we call a receiver of isochronous data?
>> [WMS] * other __destination___________
To setup a "conversation" (maybe yet another vocabulary word),
the listener may send frames towards the talker. For this,
listener is the source and the talker is the destination.
To avoid such confusion, some standards have chosen to use
distinct terms for the conversation source&sink stations.
This avoids the problem of refering to the isochronous
destination as the negotiation frame source.
That is the reason for _not_ using source and destination.
While I like talker and listener, these may be too 1394
centric, so perhaps others can chime in?
>> 1) Device discovery. How does a listener discover the talker?
>> [WMS]Out of scope for 802 standards. Handled by UPnP, Rendezvous, etc.
Agreed.
>> [WMS] Bandwidth is not a fixed quantity. Throughput for a 100
>> Mbps link will be far less for 64 byte frames than 1500 byte frames.
There are a variety of ways of dealing with the per-frame overhead.
In general, consumed bandwidth could be phrased as the number of data
bytes transferred within each 125us interval _plus_ the number of
frame-overhead bytes. There could also, perhaps, be some link-dependent
overheads.
As you noted, the computation of consumed BW is not exactly proportional
to data bytes, but could perhaps be (conservatively stated) as a constant
number of additional data bytes.
While the measurement resolution and approximations are reasonable TBDs,
the concept seems necessary: requests for cannot-be-guaranteed link BWs
should be refused.
>> [WMS] How is "port" identified in a MAC frame? Would looking
>> inside be layer bleeding?
There are a variety of ways this could be done, including:
1) Bits within the multicast address.
2) Bits following the innermost type/length field.
I suspect there will be some tradeoffs between efficiency and
purity, but those options can be clarified as we progress in
our studies.
The fundamental higher level choice is not where the multicast
"channel" bits are located, but what they represent. If the
multicast channel address is {mac,plug}, there is no need to
administer this through a central authority.
(Note that I have changed notation in mid-stream, from
port==>plug, to avoid overloading the meanings of "port").
On the other hand, numbers associated with a central authority
are likely to be more compact.
Having dealt with both, I tend to prefer the {mac,plug} model,
since defining and migrating the central authority can be hard.
>> [WMS] What about policing (Making sure sources obey their contract)?
In 802.17, the MAC was assumed to enforce the policing.
Bridge ports could also do this, since they are likely to know
the volume of traffic allowed to flow through them.
Bridges are likely to do at least a primitive form of policing,
to ensure that some asynchronous frames can always get through.
>> [WMS] Is traffic shaping required for VBR? Leaky bucket?
Traffic shaping is definitely required at the talker, probably
at 100Mb ports of a bridge, and possibly at 1Gb ports of a bridge.
To reduce bursting and bunching, some have advocated sending
in each cycle, sending what has accumulated in the last cycle.
For wired 100Mb and 1Gb, a cycle time of 8kHz seems reasonable.
This could be thought of as a constrained leaky bucket, or a bursting
TDMA channel, although both analogies are somewhat strained.
DVJ
David V. James
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 Shvodian
>> William-r63101
>> Sent: Wednesday, November 24, 2004 8:40 PM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: Re: [RE] Categories of RE development
>>
>>
>> David, Interesting points. Comments below.
>>
>> Bill
>>
>> -----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: Wednesday, November 24, 2004 6:04 PM
>> To: STDS-802-3-RE@listserv.ieee.org
>> Subject: [RE] Categories of RE development
>>
>> All,
>>
>> In recent discussions with others, I have been trying to scope
>> and categorize the problems associated with
>> 802.3 Study Group Residential Ethernet.
>>
>> The following is a first pass summary, with an attempt to
>> identify the distinct categories of work. The intent of this is
>> to allow folks to focus on distinct areas, while maintaining a
>> consistent view of the whole.
>>
>> This is still a rough draft, but I thought it helpful to
>> distribute this before the Thanksgiving vacation.
>> Credit is due to several others, that stimulated my thoughts.
>> They have not reviewed this content and thus could not be safely
>> listed as supporters/conspirators.
>>
>> A) Vocabulary. A few commonly used terms.
>> I have an historical bias but no strong preferences.
>> 1) What should we call a sender of isochronous data?
>> * talker
>> [WMS] * other _source___________
>> 2) What should we call a receiver of isochronous data?
>> * listener
>> * sink
>> [WMS] * other __destination___________
>>
>> B) Using these terms, a crude breakdown of tasks could be:
>>
>> 1) Device discovery. How does a listener discover the talker?
>> For example, how does the TV discover tuners, cable box,
>> etc.?
>>
>> Notes: This is probably out of scope, since this work
>> is more device-centric and being done by multiple
>> non-802 groups.
>>
>> [WMS]Out of scope for 802 standards. Handled by UPnP, Rendezvous, etc.
>>
>> 2) Admission control. How is the bandwidth allocated?
>> a) The bridges between the talker and listener are set
>> to forward desired traffic, up to a specified bandwidth
>> limit. If not possible, due to limited bridge forwarding
>> tag entries, a rejection is indicated.
>> b) The cumulative specified bandwidths for each link are
>> ensured to not exceed the capacity of the link. If not
>> possible, without exceeding the link capacity, a rejection
>> is indicated.
>>
>> Notes: This could possibly be a variant of GMRP, based on
>> the GARP protocols defined in 802.1D. A distinction is
>> that only paths between listeners and one talker are
>> required (a many-to-many group allocation would be inefficient).
>>
>> [WMS] Bandwidth is not a fixed quantity. Throughput for a 100
>> Mbps link will be far less for 64 byte frames than 1500 byte frames.
>>
>> 3) Clock synchronization. How are clocks synchronized?
>> This involves two tasks, although they most likely share
>> many of the same state machines and frame transmissions.
>> a) Clock master selection. The clock-master station is
>> selected from among the multiple candidates. This
>> would be done with an STP like precedence specifier
>> (weight plus MAC-48 tie-breaker).
>> b) Adjacent sync. On point-to-point links, the link-local
>> clock-slave synchronizes its clock to the link-local
>> clock-master station.
>> c) Bridge sync. With "magic", the bridge synchronizes
>> its bridge-local clock-master ports to the selected
>> clock-slave port.
>>
>> Notes: The details of this are really a link-level spec,
>> although some constraints on the timing of bridge-sync
>> "magic" may be necessary.
>>
>> 4) Transmission gating. How are isochronous frames gated?
>> Some proposals have indicated gating pending traffic
>> at the start of each 125us interval.
>>
>> Note: This is really a form of "micro" admission control.
>> However, calling this "gating" may be less confusing.
>>
>> Note: The simplest solution would be to place the same
>> timing constraints on stations and bridge gating, which
>> could imply "reclocking" to avoid cumulative jitter.
>>
>> 5) Formats. Formats of a few things need definition:
>> a) Frames. The format depends on a few things:
>> How should an isochronous frame be distinguished?
>> * Distinct multicast address?
>> * Distinct type/length code?
>> What is an isochronous channel number?
>> * Allocated from a central pool?
>> * A {mac,port} concatenation, where:
>> mac identifies the talker
>> port is a subconnection within the talker
>> [WMS] How is "port" identified in a MAC frame? Would looking
>> inside be layer bleeding?
>> What forms of time stamps are necessary?
>> * End transmission time?
>> * Link transmission time?
>> * Sync marks within the data?
>> b) Service interface. What service interfaces
>> primitives/parameters are required?
>> * Clock synchronization
>> * Timed delivery
>>
>> Thoughts? What has been missed? What should be added?
>>
>> [WMS] What about policing (Making sure sources obey their contract)?
>> [WMS] Is traffic shaping required for VBR? Leaky bucket?
>>
>> DVJ
>>
>> David V. James
>> dvj@alum.mit.edu
>>