Subject: RE: [Diffserv] Intuitive EF ?

From: Shahram Davari <[email-masked]>
Date: Wed, 26 Jul 2000 10:58:32 -0700

Hi,

>-----Original Message-----
>From: Brijesh Kumar [mailto:[email-masked]]
>Sent: Wednesday, July 26, 2000 12:36 PM
>To: 'Shahram Davari'; 'Grenville Armitage'; 'DiffServ'
>Subject: RE: [Diffserv] Intuitive EF ?
>
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf
>> Of Shahram Davari
>> >This third point appears critical. I never saw the problems raised
>in
>> >section 1.2.1 of draft-charny-ef-definition-00.txt since my
>> >definition of "average" doesn't involve an interval with arbitrary
>> >start/stop times. The start time is always fixed to be the moment
>> >the first bit of an EF packet is transmitted, and the stop time
>> >is arbitrary and greater than MTU/C beyond the start time. To me
>> >this was always the intuitive interpretation of RFC2598's intent.
>>
>> An RFC which is subject to intuitive interpretations leads to
>> interoperability issues.
>
>And what are those interoperability issues exactly? I think you meant
>something else (all those horrendous performance implications etc.
>described in the draft;-)).
>
>> >Re-analyzing sections 1.2.1 and 1.2.2 using my interpretation of
>> >"average" results in everything working out fine (apparently).
>
>If you pick up any arbitrary interval then of course definition is not
>valid. But you do agree that if the start time is always fixed to be
>the moment the first bit of an EF packet is transmitted, and the stop
>time is arbitrary and greater than MTU/C beyond the start time, it
>fixes the problem in the 1.2.1 in your draft.
>

Yes it solves 1.2.1.

>
>> 1.2.1 works fine, but 1.2.2 DOES NOT. For example consider
>> the time interval
>> of 4T to 6T which is 3T that starts with an EF bit
>> (consistent with you
>> interpretation). This time interval (3T) is greater than 2T
>> (which is the
>> time interval to send an MTU size packet at configured rate
>> C/2).
>
>As the draft points out, the underlying reason for this problem is
>that the scheduler cannot forward EF traffic faster than it arrives.
>However, it can be easily seen that the existence of internal delay
>causes one packet to be inside the router at all times.
>
>While the addition of the condition that EF aggregate must receive its
>configured rate only when the EF aggregate is backlogged may not
>suffice in this case, but  adding a more explicit condition that the
>configured rate is only achievable when EF aggregate arrival rate
>exceeds (or equal to (?)) the configured rate should remove the
>problem described in the 1.2.2. Let us see what you have against these
>two simple conditions.
>

Although your proposed statement removes the problem of 1.2.2, but it
creates another problem. And that is RFC-2598 conformance definition then
can't be applied to any flow at all. Because:

1) IF the arrival rate is greater than the configured rate then you can't
deliver EF-PHB, because you will have packet loss in the router.

2) If the arrival rate is smaller than the configured rate, then as you said
the conformance definition of RFC-2598 does not apply.

So there is no other traffic left. Is there?

Regards,
-Shahram 

>Cheers,
>--brijesh
>Ennovate Networks Inc.

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/

---

From: "Brijesh Kumar" <[email-masked]>
Date: Wed, 26 Jul 2000 14:34:08 -0400

> From: Shahram Davari [mailto:[email-masked]]
>
>
> creates another problem.

OK so you agree that both problems (1.2.1 and 1.2.2) that are
described in the draft can solved by adding simple text explanations
to EF draft.

> And that is RFC-2598 conformance
> definition then

That is implied by the service definition that uses this PHB. So it is
not a problem.

> the conformance definition of RFC-2598 does not apply.

As others have pointed out, except wordings in the RFC, it is
perfectly nice condition to have.

Basically, adding 4-6 line text clarifications to RFC 2598 may
suffice. However, you did a good analytical job in defining the
problems in the draft.

Cheers,

--brijesh
Ennovate Networks Inc.

---

From: Rajesh Talpade <[email-masked]>
Date: Wed, 26 Jul 2000 15:19:35 -0400 (EDT)

> deliver EF-PHB, because you will have packet loss in the router.

huh ?? if the arrival rate of EF traffic at a router
exceeds the configured rate over a sustained period, packet loss will 
result no matter what definition one uses for EF-PHB.

i don't see the EF-PHB definition in rfc2598 precluding packet loss
under such circumstances.

it is more a matter of appropriate policing by the network operator
to ensure that such conditions are not induced.

rajesh.

-- 
Rajesh R. Talpade [email-masked] 973 829-4261
Telcordia Technologies

---

From: Anna Charny <[email-masked]>
Date: Wed, 26 Jul 2000 16:40:30 -0400

Bijesh,

>described in the draft can solved by adding simple text explanations

First, I am also happy to hear that you do agree that there is some problem 
in the RFC.

Regarding your comment above:  in my message to Grenville which I have 
forwarded to the list
about half an hour ago, I tried to explain why it is that "simple" text 
explanations are entirely untrivial, if your goal is to remove the 
ambiguity.   I will not reiterate it here - but please let me know if you 
see the difficulty.

  We did try hard to just add simple explanation. If you go back to the 
discussion on the mailing list about two months ago, you will see where we 
stumbled.

It is possible we just did not think hard enough. Perhaps you can offer a 
simple text change that will address  all the issues we can see, (and does 
not introduce new ones :-)).  That would be really very helpful.

>That is implied by the service definition that uses this PHB. So it is

Noone said it was a problem, though.  Seems there is some disconnect 
here.  I will try to rephrase what was said to avoid repeating the same 
thing:  since EF is expected to be undersubscribed, it means that  the 
input rate IS smaller than the configured rate AS A RULE.  Therefore,   the 
definition of EF PHB should really make some sense precisely when the input 
rate is smaller than the configured rate.  And we think it does not, and 
hence needs to be fixed.   Do you disagree with that?

>suffice. However, you did a good analytical job in defining the

Thanks for the compliment. Please do offer the 4-6 line text if you know 
what it should be.

Anna

>Ennovate Networks Inc.

---------------------------------------
Anna Charny
Cisco Systems, Inc
300 Apollo Drive
Chelmsford, MA  01824
Tel. (978)-244-8172
Fax (978)-244-8126