Subject: RE: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt

From: Shahram Davari <[email-masked]>
Date: Fri, 1 Dec 2000 04:45:05 -0800

Hi Brian,

I will wait for the authors to respond. But just for the record, after long discussions with the authors (specially with Fred Baker) it was agreed in version 2 that a simple TB is a TB that can't go negative and as a matter of fact according to my suggestion it was included in the main body of the draft and the negative TB (which is not compatible even with other IETF RFCs) was moved to the appendix (the relevant email is attached).

Then suddenly without WG consensus the authors decided to move the negative TB to the main body and call it a simple TB and move the positive TB to the appendix A, in version 3. Then they kept it in version 4 and 5, and without  directly answering my concerns rather stating a vague argument like you:

"... believe that they considered your comments as well as previous discussion of these points in the WG before deciding which way to go."

This kind of statement is not acceptable to me as a WG member, and I demand a valid technical reason that will have the WG consensus.

Yours,
Shahram Davari
Systems Engineer
Product Research Group
PMC-Sierra, Inc. (Ottawa)
Phone: (613) 271-4018
Fax:   (613) 271-7007

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Thursday, November 30, 2000 6:36 PM
> To: Shahram Davari
> Cc: Diff Serv
> Subject: Re: [Diffserv] Re: I-D 
> ACTION:draft-ietf-diffserv-model-05.txt
> 
> 
> Shahram,
> 
> I will leave the authors to respond, but I believe that they 
> considered your 
> comments as well as previous discussion of these points in the WG
> before deciding which way to go.
> 
>    Brian
> 
> Shahram Davari wrote:
> > 
> > Hi Brian,
> > 
> > I had concerns regarding the negative token bucket, which 
> was addressed in version 2, but returned back as an open 
> issue in version 3 (which was the version discussed in 
> Pittsburgh), and was never addressed in version 4 and 5. I 
> would like them to be addressed before this draft goes forward.
> > 
> > Thanks,
> > -Shahram
> > 
> > > -----Original Message-----
> > > From: Brian E Carpenter [mailto:[email-masked]]
> > > Sent: Thursday, November 30, 2000 6:07 PM
> > > To: Diff Serv
> > > Subject: [Diffserv] Re: I-D 
> ACTION:draft-ietf-diffserv-model-05.txt
> > >
> > >
> > > Diffservers,
> > >
> > > We are hoping that this version will be last called very 
> soon after
> > > the San Diego meeting. According to the discussion in Pittsburgh,
> > > there are no open issues. This is labelled "Preliminary Authors'
> > > Review DRAFT" because there wasn't time for all the authors to
> > > approve the text before release. Thanks to Andrew Smith 
> for producing
> > > this version.
> > >
> > >    Brian Carpenter
> > >    diffserv co-chair
> > >
> > > [email-masked] wrote:
> > > >
> > > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > > This draft is a work item of the Differentiated Services
> > > Working Group of the IETF.
> > > >
> > > >         Title           : An Informal Management Model for
> > > Diffserv Routers
> > > >                           *****Preliminary Authors' 
> Review DRAFT****
> > > >         Author(s)       : Y. Bernet, S. Blake, D. 
> Grossman, A. Smith
> > > >         Filename        : draft-ietf-diffserv-model-05.txt
> > > >         Pages           : 54
> > > >         Date            : 29-Nov-00
> > > >
> > > > This memo proposes an informal management model of 
> Differentiated
> > > > Services (Diffserv) routers for use in their management and
> > > > configuration.  This model defines functional datapath
> > > elements (e.g.
> > > > classifiers, meters, actions (e.g. marking, absolute
> > > dropping, counting,
> > > > multiplexing), algorithmic droppers, queues and schedulers.
> > > It describes
> > > > possible configuration parameters for these elements and
> > > how they might
> > > > be interconnected to realize the range of traffic
> > > conditioning and per-
> > > > hop behavior (PHB) functionalities described in the Diffserv
> > > > Architecture [DSARCH].
> > > >
> > > > A URL for this Internet-Draft is:
> > > > 
> http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt
> > >
> > > _______________________________________________
> > > diffserv mailing list
> > > [email-masked]
> > > http://www1.ietf.org/mailman/listinfo/diffserv
> > > Archive:
> > > http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
> > ent/maillist.html
> 
> _______________________________________________
> diffserv mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/diffserv
> Archive: 
> http://www2.ietf.org/mail-archive/working-groups/diffserv/curr
ent/maillist.html

Subject: RE: [Diffserv] Model Draft TB?
From: Shahram Davari <[email-masked]>
To: 'Fred Baker' <[email-masked]>, Shahram Davari <[email-masked]>
Date: Thu, 29 Jun 2000 12:46:38 -0800

Hi Fred,

Thanks for your kind response. I think the following paragraph in section 5:

" The fact that data is organized into variable length packets introduces
some uncertainty in this conformance decision. When used in a Scheduler,
a leaky bucket releases a packet only when all of its bits would have
been allowed: it does not borrow from future capacity. When used in a
Meter, a token bucket accepts a packet if any of its bits would have
been accepted and "borrows" any excess capacity required from that
allotted to equivalently classified traffic in a previous or subsequent
interval. Note that [SRTCM] and [TRTCM] insist on stricter behavior
from a meter than the model here insists on."

Needs to be changed to:

" The fact that data is organized into variable length packets introduces
some uncertainty in this conformance decision. When used in a Scheduler,
a leaky bucket releases a packet only when all of its bits would have
been allowed: it does not borrow from future capacity. When used in a
Meter, a token bucket accepts a packet only if all of its bits would have
been accepted and does not borrow excess capacity required from future
capacity.  Note that this is consistent with [SRTCM] and [TRTCM]."

Regards,
-Shahram

>-----Original Message-----
>From: Fred Baker [mailto:[email-masked]]
>Sent: Thursday, June 29, 2000 3:31 PM
>To: Shahram Davari
>Subject: RE: [Diffserv] Model Draft TB?
>
>
>At 09:03 AM 6/29/00 -0700, Shahram Davari wrote:
>>But we should design it with valid data, and valid 
>justification and be
>>consistent to other IETF documents and standards.
>
>No problem. Can you interact with the design and tell us what 
>we need to fix?
>

---

From: Andrew Smith <[email-masked]>
Date: Mon, 04 Dec 2000 11:03:05 -0800

Shahram,

My apologies on missing the "If T(t-) - C = 0" typo (again). I fixed the other 
typo there but not this one that you have repeatedly pointed out - will do so 
next time.

On the other issues, I'm not sure you are raising anything new that Fred and 
Steve have not responded to already - I suggest you sit down with them, and 
maybe with Brian also, next week to discuss it again.

Andrew
(editor)

Shahram Davari wrote:

> Hi Andrew,
> 
> I raised a number of issues many times during the course of this draft, but I haven't seen them being addressed. Last email that I sent was regarding version -04 of the draft, which was left un-answered. So I urge you to take some time to address my concerns about this draft. 
> 
> Here is a brief:
> 
> 1) First of all the following typo is still in Appendix A of the draft despite being stated before:
> 
> "If T(t-) - C = 0, the packet conforms and T(t) = T(t-) - C. Otherwise,
> the packet does not conform and T(t) = T(t-)."
> 
> Must be changed to:
> 
> "If T(t-) - C >= 0, the packet conforms and T(t) = T(t-) - C. Otherwise,
> the packet does not conform and T(t) = T(t-)."
> 
> 2) I believe after a heavy discussion, the authors agreed that a simple token bucket is not a token bucket that its counts can go negative, and it was corrected in version -02, but I see it come back again in the future versions.
> 
> Let me explain again what the problem is:
> 
> A) Nobody (at least that I know) uses this kind of TB.
> B) A TB which can go negative has many disadvantages, which are not mentioned in the draft at all. First of all it is more likely to drop small TCP ACK/SYN packets than a normal TB (i.e., a positive one). The reason is that when the TB count is negative it does not accept any packet, however small they may be until the count goes positive. Secondly it has granularity problem. By that I mean for example if one wants to restrict the burst to MTU, then the TB depth must be set to 1-bit. And if you do that you can't basically accept any back to back packets at all, no matter how small they are. 
> C) The same behavior that a negative TB of size B is looking after, could be constructed using a normal TB (the one that can't go negative) that has a size equal to B+MTU. By using a normal TB of bigger size, still the average rate will remain the same and you also won't have the problems that I mentioned in the bullet above and the problems of strict TB as mentioned in the draft won't exist any more. In other words a strict TB of bigger size will behave as a loose TB.
> 
> 3) The first bullet of the disadvantages of strict TB is void, because the authors themselves have given the solution to it. Basically everybody knows that the TB depth must be greater than or equal to MTU. By comparison the problem with the negative TB could be said to be that you can't set the burst size to any value smaller than MTU.
> 
> 4) Page 49 talks about the options that exist, if the size of the arriving packet exceeds the TB count. First of all if bullet 2 is talking about strict TBs, it is wrong. Because if you read SRTCM and TRTCM, you will see that in them if a packet is not accepted it does not cause any tokens to be added to the TB, while bullet 2 suggests that: "remembering that the token bucket size must be added to the TB variable rather than simply setting it "full". Also SRTCM and TRTCM always add token till the TB is full. If the second bullet is not talking about the strict TB, then why is it omitted from that list?
> 
> 
> So here is my suggestion:
> 
> 1)Let's add the disadvantages of the loose TB.
> 2)let's mention that you could achieve the loose TB performance using the strict TB with a larger size.
> 3)Let's either correct bullet 2 page 49, or add a new bullet that has strict TB as another option.
> 4)Let's also mention the structure of strict TB in section 5.1.3.
> 5)If possible I suggest changing the name form loose and strict to negative and positive respectively. The reason is that as I mentioned you could always achieve a loose performance by increasing the bucket depth of a strict TB.
> 
> Thanks for you consideration.
> 
> Shahram Davari
> Systems Engineer
> Product Research Group
>> From: Andrew Smith [mailto:[email-masked]]
>> Sent: Thursday, November 30, 2000 3:38 PM
>> To: [email-masked]
>> Subject: [Diffserv] Re: I-D ACTION:draft-ietf-diffserv-model-05.txt
>> 
>> 
>> Please excuse the "*****Preliminary Authors' Review 
>> DRAFT****" legend in this 
>> draft - I forgot to remove it before submitting: this is, 
>> AFAIK, the current 
>> consensus of the authors and reflects most of the comments 
>> received up to this 
>> point. There are still a couple of open issues that I'll list 
>> in a separate message.
>> 
>> Andrew Smith
>> (editor of this draft)
>> 
>> 
>>>                           *****Preliminary Authors' Review DRAFT****
>>> 	Author(s)	: Y. Bernet, S. Blake, D. Grossman, A. Smith
>>> This memo proposes an informal management model of Differentiated
>>> Internet-Drafts are also available by anonymous FTP. Login 
>> 
>> with the username
>> 
>>> "anonymous" and a password of your e-mail address. After logging in,
>>> type "cd internet-drafts" and then
>>> 	"get draft-ietf-diffserv-model-05.txt".
>>> 
>>> A list of Internet-Drafts directories can be found in
>>> http://www.ietf.org/shadow.html 
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>> 
>>> 
>>> Internet-Drafts can also be obtained by e-mail.
>>> 
>>> Send a message to:
>>> 	[email-masked].
>>> In the body type:
>>> 	"FILE /internet-drafts/draft-ietf-diffserv-model-05.txt".
>>> 	
>>> NOTE:	The mail server at ietf.org can return the document in
>>> 	MIME-encoded form by using the "mpack" utility.  To use this
>>> 	feature, insert the command "ENCODING mime" before the "FILE"
>>> 	command.  To decode the response(s), you will need "munpack" or
>>> 	a MIME-compliant mail reader.  Different MIME-compliant 
>> 
>> mail readers
>> 
>>> 	exhibit different behavior, especially when dealing with
>>> 	"multipart" MIME messages (i.e. documents which have been split
>>> 	up into multiple messages), so check your local documentation on
>>> 	how to manipulate these messages.
>>> 		
>>> 		
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> draft-ietf-diffserv-model-05.txt
>>> 
>>> Content-Type:
>>> 
>>> Message/External-body
>> 
>> 
>> -- 
>> ******************************************************************
>> Andrew Smith                            tel: +1 415 345 1627
>> 1001 Chestnut St.                       fax: +1 415 345 1827
>> San Francisco, CA 94109, USA          email: [email-masked]
>> ******************************************************************
>> 
>> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html