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

[RE] Preliminary report, 802.1 liason

Title: Preliminary report, 802.1 liason
(Note, this is being written on Wednesday afternoon, May 11, in mid-Atlantic. The 802.1 meetings will continue today and tomorrow, and there will be ResE-related discussions tomorrow ... I am hoping that Yong Kim or Dirceu Cavendish will give us a final report on Friday.)

There was a good two hour session starting about 1600 on May 9 at the 802.1 Interim in Berlin. Much of it consisted of the presentation available at http://www.ieee802.org/1/files/public/docs2005/liaison-mikejt-rese-objectives-requirements-0505.pdf and the resulting discussion. From my memory, here are the key points raised (others present are invited to add their comments and correct any inaccuracies ... there will also be minutes published later, those will also be available at the 802.1 website http://www.ieee802.org/1/):

  1. I noted that there have been three basic proposals for ResE solutions: The parallel-MAC approach (Spyder), the EPON-like TDM approach, and the bridge-based approach. I emphasized that my PERSONAL favorite was the bridge-based one, but all three required bridge support for the total solution, so that’s why I was there.
  2. There was little controversy over the objectives, except perhaps with the meaning of some of the wording (“isochronous” means lots of different things to different people ... ). In particular, there seemed to be understanding of the desire to have guaranteed bandwidth and latency for established streams (once a stream is going, it will continue to get its expected QoS regardless of what kind of other offered traffic there might be on the network).
  3. Some of the detailed goals were somewhat controversial at first, but once the constraints were explained, there was less of a concern. The particular ones were the latency requirement of 2ms on a “worst case typical” ... meaning an 8 hop net.  Some also thought the requirement to support 100baseT as unnecessary, but again, when the idea of the “Ethernet speaker” or the “switch in the DVD” to allow daisy-chaining were brought up, the paramount cost constraints of the CE market were understood.
  4. The strong desire to support 1588-quality time synchronization took a while to explain, but Geoff’s slides helped with that. The need to support this over layer 2 vs the existing over-layer-3 approach provoked an extended conversation. Many, though not all, in the room understood the need (a: commercial, in the sense that 1588 algorithms would much easier to implement as layer 2 in a chip or chipset –something needed for CE-type low cost applications; and b: specification, in the sense that defining when a frame starts being sent on the media is much easier if done in the MAC or just above it, but before any queuing).
  5. There was even more discussion about the need for admission control ... not all of it coming from myself or from Jim Battaglia from Pioneer (the only CE vendor represented). This, apparently, is an old conversation that has happened periodically for some time. There were several threads:
    1. Where would admission control take place? Is this something only needed at the “edge” of the network, or do bridges need to participate. There was a developing, although very incomplete, consensus that perhaps an incremental approach might work: admission control at the edge would vastly improve things, and that including bridge participation could make it “perfect” ... a desirable method would be one that allowed consumers to incrementally add this capability.
    2. Admission control could perhaps be based on some earlier work that was done during the 10-100 transition back in the mid-90’s. This is another “reduced RSVP” idea somewhat like the one people in the SG are investigating. Apparently a version of this is already implemented in the Windows OS. I’m promised further information on this ...
    3. There already are multiple places where admission control could be enforced. For example, there are the well known priority queuing methods defined in 802.1D, but there is all ingress “metering” defined in 802.1Q that allows for metering of flows identified by destination MAC Address, VLAN, as well as priority. We never looked at ingress enforcement, just egress, so this is interesting ... the problem is that this metering is currently ill-defined, but at least it’s a hook into existing standards.
    4. The most popular “tag” for labeling streams and using for admission control enforcement was the traffic class fields currently used for priority. There are only 8 values, and overlaying our requirements on top of the existing priority use may be a problem. The latest SG ideas of using the multicast MAC address was not popular, but I didn’t really understand the reasoning very well. I expect that after we have a chance to talk more with the parties involved we can come to an understanding one way or the other.
  6. The desire for pacing was the most controversial. This was apparently such a violation of the way 802.1 bridges have  always been designed (for good reason) that there was very little sympathy for the desire to have fixed length buffers at all points in the network (even just for the streaming traffic), nor to use pacing as a way to simplify admission control enforcement. As expected, getting this into the ultimate solution will be a very steep climb and may not be worth the effort.

Post-meeting discussions confirmed that there is definitely sympathy within 802.1 to meet our objectives, and that many there would support a PAR and that the PAR could be passed in the Fall meeting (it’s probably too late to get everything together at the Summer meeting in SF, but there is still a possibility). Furthermore, there might be some useful synergy with the congestion management group, since they also need some sort of admission control (although for a complete orthogonal reason: they want their streams to be throttled so that packets are never dropped, and we want streams to NEVER be throttled).

Anyway, there’s lots of work to do:

  1. Contact the 1588 chair and ask about the possibility of restarting the WG in cooperation with 802 to come up with a 1588-REV that supports layer 2 operation, or to get the right people from his old WG to work on a solution solely with 802. Document various layering approaches and socialize them with 802.1 and 802.3 (maybe even 802.15.3 and other wireless groups).
  2. Gather together more of the old information on previous layer 2 approaches and evaluate them. Various 802.1 members will help with this.
  3. Document and discuss various alternatives for admission control based on the existing “levers” within 802.1 specs. It would be desirable to come up with a method that makes the “incremental adoption” process work (start with admission control at the edge and work inward ... allow existing bridges to carry QoS data, but with some loss of guarantees).
  4. Document the advantages of pacing in a more forceful manner, and, perhaps, show how “pacing” bridges could interoperate with existing bridges. If no adequately convincing reasons are found, then drop it from the objectives.

Respectfully, your acting chair ....

--
---------------------------------------------------------------
         Michael D. Johas Teener — mikejt@broadcom.com
office +1-408-922-7542 cell +1-831-247-9666 fax +1-831-480-5845
http://public.xdi.org/=Michael.Johas.Teener - PGP ID 0x3179D202
---------------------------------------------------------------