Subject: [Diffserv] Re: comments draft-ietf-diffserv-rfc2598bis-00.txt

From: "Bruce Davie" <[email-masked]>
Date: Tue, 6 Mar 2001 13:27:17 -0500

My co-authors and I have collected all the comments that have been made so
far on the list regarding draft-ietf-diffserv-rfc2598bis-00.txt. The
following mail summarizes the issues raised and proposes a resolution for
each issue. In addition to the issues listed below, Dan Grossman made a
couple of suggestions for clarification that I didn't bother to list below
but which made sense and will be taken care of.

If you feel the need to reply to these on the list, it might be best to
break the issues out into separate threads.

Bruce Davie
---------------------------

Issue 1. Lack of mention of jitter in the abstract.

This was a simple omission, abstract will be made consistent with the rest
of the document. As noted in Section 2.4, per-hop jitter can be bounded if
the offered load to a node is also appropriately bounded.

Proposal: add the words ", low jitter" after "low loss" in the abstract.

Issue 2. Use of "speed-of-light" to cover fixed propagation delays.

Proposal: replace "speed-of-light delay" with "fixed propagation delay"

Issue 3. Definition of packet arrival & departure times.

Dan Grossman makes the point that the arrival time had better be defined as
time of arrival the last bit of the packet *including layer 2 trailer, if
present*, since the packet isn't available for forwarding before that time.
And then the departure time should be similarly defined.

Proposal: make the change as Dan suggests

Issue 4. How can a scheduler run early?

Dan asked this question if reference to 2.1, fourth para.

As the text says, we can consider the scheduler to be running "early" if it
delivers a packet earlier than the ideal time. I'm not quite sure how to
make this clearer than it already is.

Issue 5. Naming issue - colorblind, color-aware, etc.

I have yet to come up with a pair of names that makes everyone happy. My
current favorite is:

 "aggregate behavior" (equations 1 & 2, with error term E_a)
and "packet-identity-aware" (equations 3 & 4, error term E_p)

Some people like colorblind but many found it confusing. I think "aggregate"
works pretty well, since it defines the behavior of the EF aggregate
(without regard to individual packets). I prefer "packet-identity-aware" to
Dan's suggested "individual flow" because the equations themselves refer to
packets, not flows - the issue of microflow (mis)ordering is handled by a
piece of text, not the equations.

Proposal : replace "colorblind" with "aggregate behavior"; leave
"packet-identity-aware" unchanged.

Issue 6. Layer 2 overhead.

Dan asked if it was really OK to leave layer 2 overhead out of the
definition of l_j and R.
My opinion is that it is OK, and that implementors simply need to make sure
that, if a scheduler is configured to deliver service at rate R as defined
in bits of IP packet per second, that it can do so while dealing with the
worst case layer 2 overhead. This exact issue arises in the int-serv service
definitions and I don't think there is any significant issue here.

Proposal: no change.

(I could be persuaded to add a few words in the appendix on this issue.)

Issue 7. Unclear definitions of F_j and D_j

Dan points out that when we say "packet that arrived", we don't say where it
arrived. The intent is that the packet may have arrived on any interface of
the DS-node in question.

Proposal: add clarifying text per Dan's suggestion: "packet that arrived at
any interface to the node"

Issue 8. Additional security considerations:

Proposal: insert Dan's text verbatim:

"In addition, traffic conditioning at the ingress to a DS-domain MUST ensure
that only packets having DSCPs that correspond to an EF PHB when they enter
the DS-domain are marked with a DSCP that corresponds to EF inside the
DS-domain.  Such behavior is as required by RFC 2475.  It protects against
denial-of-service and theft-of-service attacks which exploit DSCPs that are
not identified in any TCS provisioned at an ingress interface, but which map
to EF inside the DS-domain."

Issue 9. Multiple instances of EF PHB in a domain

Proposal: Add some text in the appendix to mention this possibility and its
effect on implementations.

Issue 10. Other schedulers in the appendix

Dan suggested adding mention of EDF; since there are a million schedulers
and the appendix is only there for illustrative purposes, I'm not inclined
to do much here. This topic is given more coverage in the
informational-track draft-ietf-diffserv-ef-supplemental-00.txt, to which we
can make a reference.

Issue 11. How to test for comformance to the "packet-identity-aware"
equations

Alessio Casati requested some clarification on how a device's conformance to
the "packet-identity-aware" equations could be tested "especially with
regard to the notion of
relative ordering of packets arriving at different interfaces".

In theory, two packets can't arrive at *exactly* the same time on different
interfaces. However, if two or more packets arrive at almost the same time
and the difference between their arrival times can't be measured, then it is
acceptable to use a random tie-breaking method (a virtual coin-toss) to
decide which packet arrived "first". It is precisely for this reason that
devices with large numbers of interfaces, even if they have excellent
schedulers, tend to have large values of E_p.

Proposal: Add a paragraph near the end of section 2.2 (after equations 3 &
4) along the following lines:

For the purposes of testing conformance to these equations, it may be
necessary to deal with packet arrivals on different interfaces that are
closely spaced in time. If two or more EF packets destined for the same
output interface arrive (on different inputs) at almost the same time and
the difference between their arrival times can't be measured, then it is
acceptable to use a random tie-breaking method to decide which packet
arrived "first".

_______________________________________________
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

---

From: Kathleen Nichols <[email-masked]>
Date: Tue, 20 Mar 2001 11:44:23 -0800

Bruce, et al,
I have another comment on your draft. I did make this comment
to you before you wrote the draft, so I'd assumed it was
included. There was a clause in rfc2598 that was required
by the WG by consensus (this did not come from the orignal
3 authors) that is in section 2, paragraph 2:

  "If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation MUST include some means to limit the damage EF traffic
   could inflict on other traffic (e.g., a token bucket rate limiter).
   Traffic that exceeds this limit MUST be discarded. This maximum EF
   rate, and burst size if appropriate, MUST be settable by a network
   administrator (using whatever mechanism the node supports for non-
   volatile configuration). The minimum and maximum rates may be the
   same and configured by a single parameter."

You draft states in section 2.10:

   "If the EF PHB is implemented by a mechanism that allows unlimited
   preemption of other traffic (e.g., a priority queue), the
   implementation SHOULD include some means to limit the damage EF
   traffic could inflict on other traffic. This will be reflected in the
   range of supported R values as described in section 2.2."

You will note that the MUST was downgraded to a SHOULD. As WG co-chair,
I am quite certain there was no call for consensus on this change.
On the other hand, I know that we had a clear consensus to
develop the new per-hop behavior you describe and to call it the
EF PHB, so perhaps it's reasonable to assume that this should
include a change of the above clause (which was argued for
quite strongly by several parties during the writing of 2598).
Still, I believe it should be made clear that, in addition to
a change in the definition of the packet treatment at each
hop, there is a change in some of the required protections,
etc. If this is the consensus of the WG, we can certainly go
this route.

	Kathie

---

From: "Bruce Davie" <[email-masked]>
Date: Thu, 22 Mar 2001 13:20:30 -0500

Kathie,
 It really wasn't my intent to re-open an issue on which consensus had
previously been reached, and I honestly don't recall your earlier comment.
So I'd be quite happy to revert to the MUST (and I polled a bunch of my
co-authors who concur). Given that the surrounding text for the paragraph in
question is a little different than it was in RFC2598, I would propose that
it should now read:

   "If the EF PHB is implemented by a mechanism that allows unlimited
    preemption of other traffic (e.g., a priority queue), the
    implementation MUST include some means to limit the damage EF traffic
    could inflict on other traffic (e.g., a token bucket rate limiter).
Traffic
    that exceeds this limit MUST be discarded. This maximum EF rate, and
burst
    size if  appropriate, MUST be settable by a network administrator (using
    whatever mechanism the node supports for non-volatile configuration)."

Bruce

> -----Original Message-----
> From: Kathleen Nichols [mailto:[email-masked]]
> Sent: Tuesday, March 20, 2001 2:44 PM
> To: Bruce Davie
> Cc: Diffserv@Ietf. Org
> Subject: Re: [Diffserv] Re: comments
> draft-ietf-diffserv-rfc2598bis-00.txt
>
>
>
> Bruce, et al,

---

From: Kathleen Nichols <[email-masked]>
Date: Thu, 22 Mar 2001 12:13:17 -0800

Bruce,

I directed you to the relevant section of RFC 2598 when you
were meeting with Brian and Scott and I in SD and I'd thought
you were taking notes. At that time, you didn't have a "protection
clause" in your draft. Thus I thought the change of MUST to
SHOULD indicated that you wished to propose this approach. The point 
is that Brian and I believe the the earlier WG consensus on this
was forceful and applied to any PHB that could potentially starve
other traffic. Since you are reverting to the earlier WG consensus,
I think we can declare this a non-issue.

Thanks for your attention to the wording.

	Kathie