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

[RPRWG] 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>> 
>>