________________________________ IEEE 802.1 CM Study Group Draft Meeting Minutes Tuesday, May 16, 2006, 1:36 PM Tuesday (5/16/06) - 1.30pm - 4.50pm ================================================================================ 1. Recording secretary: Manoj Wadekar ================================================================================ 2. Attendees: 1 Pat Thaler, Broadcom 2 Bruce Kwan, Broadcom 3 Manoj Wadekar, Intel 4 Hugh Barrass, Cisco 5 Uri Cummings, Fulcrum 6 Gopal Hegde, Intel 7 Bob Grow, Intel 8 Kevin Daines, World Wide Packets 9 Glen Parson, Nortel 10 Tae-eun Kim, Extreme Networks 11 Yammick LE Goff, France Telecom 12 Takafumi Hamano, NTT 13 Li Xixiang, Huawei Note: this is from a list that was compiled at the beginning of the meeting. Additional participants joined later. ================================================================================ 3. Bob pointed that as of April 2006 we need to use new forms. a. AR: Pat: Check with Tony whether new form for Tutorial request is being used. ================================================================================ 4. Will start discussing milestones/schedule etc. in/after July Plenary meeting. ================================================================================ 5. Motion to approve agenda: a. M: H. Barrass S: U. Cummings b. Passes ================================================================================ 6. Presentation 1: Pat Thaler (Broadcom) : Review of CN PAR a. Reviewed Congestion Notification PAR wording (as approved by 802.1 as draft during March 2006 Plenary meeting) ================================================================================ 7. Presentation 2: Takafumi Hamana (NTT): Setting of flow identification rule for BCN-Based congestion management a. Foil 7: second scenario: Requires different treatment of BCN depending upon CPID - not part of current specification i. BCN can be configured to carry different granularity of information (E.g. internal bridge in the foil can have Rule 1- identify flow by MAC address, IP router has Rule 2 - identify flow by IP address). So, when BCN reaches the ingress RP, it installs RL with appropriate granularity. ii. Need to worry about implementation complexity b. Granularity greater than L2 - may pose challenge of congesting sources responding with higher granularity to avoid rate reduction i. Should BCN be forced only to carry L2 information? c. Foil 7: Shows a scenario where egress card is generating BCN with information about egress queue for non-CM destination. This assumes "holistic router" that has B-MA information when it reaches congested egress queue e.g. for C-MA4. Otherwise appropriate BCN can not be generated for B-MA network (it is already de-encapsulated) d. Having multiple granularity - is there any benefit? May require at least some simulation to demonstrate it. Need specific proposal how to achieve multiple rules - for further consideration. ================================================================================ 8. Presentation 3: Bruce Kwan (Broadcom): BCN 2.0 - Issues and Questions a. Sampling: Flows with smaller frames get more number of BCNs as compared to flows with larger frames. Is this appropriate? Do smaller-frames-flows get more penalized as compared to large-frame-flows? b. Queue depths - expressing in terms of packets is not a good idea. Does not work for many switch architectures in this market. c. Multiple CPs in series - CP treats RL Tagged packet with CPID != own CPID - are treated as normal packets (generate BCN only if Qoff > Qeq) - need to clarify on the block diagram in BCN 2.0 presentation d. Should BCN be triggered with Qdelta as well? - Discussion: This can only be useful in startup time when multiple flows start off. However, since Qeq is configured as small as possible, this may add small value. e. Multiple congestion points, RL behavior: Need clear documentation of what was previously verbally described - RL maintains CPID and rate information for slowest link. f. Need further characterization of Rmin (lowest managed rate). g. Solicit bit - this is old information carried over in BCN 2.0 (Sept 2005) presentation by mistake. Need to be clarified in document. h. BCN packet needs to be corrected for word alignment. i. CPID uniqueness - Use of switch MAC address can ensure this. Field is 64 bits (not 32 bits) - allowing MAC address and some more information. j. It will be good idea to define set of parameters and model environment description that simulations can be expected to provide. i. Simulations Ad-hoc team may be a good idea. ================================================================================ 9. Tutorial planning a. Preferred day moved to Monday to allow for other groups to comment. Tuesday (5/17/06) - 9.00am- ================================================================================ 10. CN TF Objectives: a. Provide control of congestion i. in networks with long-lived data flows within network domains of limited BWD product ii. by means of control messages generated at the congestion point and transmitted towards to source of the data flow. b. Will not depend on any specific upper layer protocol. c. Will be compatible with TCP/IP based protocols. There may be some TCP options that should not make use of congestion managed classes of service d. Support a BWD of at least 1Mbits, preferably 5 Mbits. e. Allow for co-existence of congestion managed classes of service and non-congestion-managed classes of service. The data traffic to be controlled by congestion notification mechanism will be segregated based upon priority bits in the VLAN tag. f. Support networks with full-duplex point-to-point links operating at a mix link rates. g. Describe messages, congestion point behavior, reaction point behavior and managed objects. h. Confine protocol messages to a domain composed solely of congestion notification capable bridges and end stations. i. Consider inclusion of a discovery protocol (e.g. LLDP) j. Will not introduce new bridge transmission selection algorithm or rate controls. k. Per flow queuing and state will not be required in bridges. ================================================================================ 11. Work a. More detailed protocol description - Manoj (and others) b. Identify protocol issues for further work i. Parameter default and range ii. Dimension iii. Discovery? iv. Cloud edge behavior c. Simulation Team - Manoj, Davide, Bruce, Uri, Raj d. Boilerplate document on draft - Norm ================================================================================ 12. Other discussion a. Need to define 802 Station requirements vs. Bridge requirements. End station document that discusses Link Aggregation, VLAN etc. ================================================================================ Thursday: AR: Manoj to arrange Simulation Ad-hoc conf. call in 2nd week of June. ================================================================================