[RPRWG] RE: new shaper text
John,
I pointed out several technical concerns.
I think consensus would be better achieved if
these points were considered, and I belived
the working group would agree.
Perhaps we could address the points, namely:
1) Is it acceptable to provide no guaranteed
classA bandwidth or latency?
2) Is it acceptable to provide no classB/C
latency bound?
I think I know the eventual answer to these,
(no and no) and its not the properties associated
with what you have proposed.
Could we stick with these issues please?
I have no desire to attack, but also no desire
to stand idle while spurious changes with
undesirable properties are being proposed.
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@xxxxxxxxxxxx
>>-----Original Message-----
>>From: JLemon@xxxxxxxxxxxx [mailto:JLemon@xxxxxxxxxxxx]
>>Sent: Wednesday, September 25, 2002 2:04 PM
>>To: dvj@xxxxxxxxxxxx
>>Cc: stds-802-17@xxxxxxxx
>>Subject: RE: new shaper text
>>
>>
>>David,
>>
>>I have ignored your increasingly hostile personal attacks via the
>>various ad hoc distribution lists in which we both participate
>>because I know that those people with whom I work closely are
>>well aware of my technical independence, my integrity, and my
>>efforts to achieve consensus. But now that you take my personal
>>email and copy your unfair reply to the entire working group, I
>>feel I have no choice but defend myself in public. This will be
>>my only mail message on this topic to the WG, and I apologize in
>>advance for wasting WG time with this message.
>>
>>I continue to try to convince several people of my (changing)
>>views of the correct direction for datapath shaping. As you
>>should be well aware, these views have been most heavily
>>influenced by you. I have run these ideas by several people with
>>several company affiliations (in terms of place of employment,
>>not in terms of any expected voting), only 2 of whom happen to
>>work for Cisco, and one of those because he happens to be my
>>technical editor for Section 2. I chose these people based solely
>>on their past level of involvement in datapath shaping
>>discussions (and Steve since he's the Section 2 technical editor).
>>
>>The changes I was trying to get your feedback on, were certainly
>>not dictated or directed by Cisco, or by any individual who might
>>work at Cisco. There isn't agreement among the 2 Cisco people
>>I've talked with on these points. And there isn't even agreement
>>on all my ideas by either one of the persons within Cisco I
>>shared these with.
>>
>>As for not following your suggestions, I don't feel any
>>compunction to blindly follow your suggestions, or any others's
>>suggestions. After listening to feedback from several individuals
>>(*not* companies), I incorporated what I thought was both
>>technically correct and most likely to achieve consensus. I then
>>went back to each of my hand picked technical advisors, including
>>you, to see what each thought of the next revision. You had been
>>the most influential on me, and I'm sorry that you decided to
>>take this route instead of continuing to work directly with me.
>>
>>jl
>>
>>-----Original Message-----
>>From: David V. James [mailto:dvj@xxxxxxxxxxxx]
>>Sent: Wednesday, September 25, 2002 10:11 AM
>>To: John Lemon
>>Cc: stds-802-17@xxxxxxxx
>>Subject: RE: new shaper text
>>
>>
>>John,
>>
>>Relative to your email and suggested change to the
>>shaper text.
>>
>>I will be voting against these changes, for reasons
>>listed below. I hope that you will clearly document
>>this lack of consensus when discussing your revisions
>>with other working group members.
>>
>>What's up? You ask my opinion, I present concerns with
>>unwritten/verbal Cisco change proposals, and implement
>>as Cisco suggested. This process does not lead towards
>>consensus, a goal of the IEEE standardization process.
>>
>>DVJ
>>
>>
>>
>>>>Removed source shaper: Not necessary. Can be done beyond the
>>>>scope of the standard.
>>
>>By making this decision, you have effectively
>>allowed the ringlet-circulation time for class-B
>>and class-C traffic to become unbounded.
>>
>>As we noted, Mike Takefman previously acknowledge
>>this was not a good idea, and Cisco had experienced
>>problems in the field with this specific problem.
>>
>>The working group needs, as we discussed previously,
>>to be involved in deciding whether:
>> 1) Class-B/C traffic has a bounded ringlet
>> circulation time (this has been the written
>> BAH proposal for over 3 months).
>> 2) Class-B/C traffic has an unbounded ringlet
>> circulation time.
>> (this was apparently Cisco's input to you)
>>
>>Having an unbounded lifetime also breaks some algorithms
>>that rely on finite lifetimes, including those being
>>considered by the BAH. And, it violates the guaranteed
>>bandwidth properties that class-B traffic would otherwise
>>have.
>>
>>>>Removed resets. Credits should be allowed to grow up
>>>>to the limit specified. Burst control is specified
>>>>by upper limit.
>>
>>By making this decision, you have effectively increased
>>the guaranteed class-A latency from N*MTU to N*N*MTU,
>>as we had noted in previous discussions of whether
>>this Cisco proposed change should be adopted.
>>
>>The working group needs, as we discussed previously,
>>to be involved in deciding whether:
>> 1) Class-A has an N*MTU latency guarantee
>> (this has historically been the BAH decision)
>> 2) Class-A is optimized for bursty traffic throughput,
>> a property previously assumed only for classB.
>> (this was apparently Cisco's input to you)
>>
>>This is what ad-hoc and working groups are for:
>>I suggest that a group decision is needed on this
>>one also.
>>
>>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@xxxxxxxxxxxx
>>
>>>>-----Original Message-----
>>>>From: JLemon@xxxxxxxxxxxx [mailto:JLemon@xxxxxxxxxxxx]
>>>>Sent: Tuesday, September 24, 2002 7:00 PM
>>>>To: dvj@xxxxxxxxxxxx
>>>>Subject: new shaper text
>>>>
>>>>
>>>>David,
>>>>
>>>>Attached is my latest version of the shaper text. I made the
>>>>following changes:
>>>>
>>>>Removed source shaper: Not necessary. Can be done beyond the
>>>>scope of the standard.
>>>>
>>>>Removed resets. Credits should be allowed to grow up to the limit
>>>>specified. Burst control is specified by upper limit.
>>>>
>>>>Finished incorporating tying of Clause 6 and Clause 9. See
>>>>especially 6.6.4 and 6.7.5.
>>>>
>>>>Lots of miscellaneous updates.
>>>>
>>>>jl
>>>>
>>>> <<jl_cls06_MAC_6.6_0924.pdf>>
>>>>
>>
>>