Subject: RE: [Tsvwg] draft-baker-diffserv-basic-classes-02.txt

From: "Jozef Babiarz" <[email-masked]>
Date: Mon, 15 Mar 2004 21:19:27 -0500

Thanks Mike for the review and comments. Currently I'm working on updating
the 02 draft and I will address your comments plus other that I have
received before the TSVWG review. I'm planning to have 03 version of the
draft available in few weeks which I will post on the mailing list.

Regards, Joe. 
Jozef Babiarz 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, March 15, 2004 12:36 PM
To: [email-masked]
Subject: Re: [Tsvwg] draft-baker-diffserv-basic-classes-02.txt

The subject draft should be progressed as an Informational RFC or BCP. 

I have the following comments: 

Nits: 

2. 1st Note under Figure 2: "were" should be "where". 

2.1 Example 1, first sentence reads bad, with the clause "in their network"
out of place. Suggest putting this clause after the parenthetical "(quality
of service)". 
Example 2, word "use" should be "using". 

2.2 "signal" should be "single" (2 times) 

2.2 Final paragraph: 2 references to "EF PDB" appear incorrect, since EF is
a "PHB". It seems that each should be either "EF PHB" or simply "PDB". 

2.3 1st line, "aggregation" should be "aggregated". In the 3rd sentence,
"service" should be "serviced". 

4.1.1 11th paragraph (note): Word "constain" should be "constraint" (2
times) 

4.1.1 12th paragraph "in to" should be "into" (one word). 

4.1.2 First sentence: "requires" should be "require". 

Other: 

1.3.1  The 2nd paragraph, which talks about "elestic" traffic, does not
apply for voice/video streams. While one might argue just how "elastic"
these are, they can not operate as stated, that is, with the sender
adjusting its transmission rate due to loss reported from the other end
(presuming to mean adjust it down) like TCP does. 

It is suggested that the first sentence should read: "Application traffic in
the internet which uses the Default Forwarding class is expected ...", since
this is the title of the section it is in. 

1.3.1 2nd paragraph: In the 2nd sentence, where it says "transferring them
to another class", it is not clear what "them" refers to. It seems to mean
"packets". It is unclear what is being described, since it implies that a
device would not follow the required handling for a DSCP, that is, instead
put them into a different class (queue). Does this intend to refer to
putting packets into the "Default Forwarding" queue, even though marked with
some (higher) DSCP or does it refer to putting packets marked with the
"Default Forwarding DSCP" into some other (presumably higher) queue? 

1.3.1 3rd paragraph refers to "limit delays" as one of the purposes of the
best effort (default forwarding) service. It seems that this is not true,
unless it means to "limit delays that might be caused on other non-best
effort traffic". As stated in the 1st paragraph, Best Effort has no further
guarantees. 

2. Note after Figure 1 (and several other places) 

It should be made clear what "alias" means as in "Class Selector 2 codepoint
[is] alias of AF11 codepoint". Does this mean "Any packet received with
DSCP=CS2 is treated as if it had DSCP¯11" or that AF11 is replaced with CS2
or vice-versa? 

Figure 1: Why are the CS1 - CS4 values out of order with the other values?
For example, shouldn't CS2 be grouped with AF21-AF23? Wouldn't this simple
change make it backwards compatible with the "TOS" bits (which 1.3.4 says
the current definition is not)? 

4.1.1 12th paragraph 

Makes a reference to "forwarding of voice packets and signaling packets with
the same very low delay forwarding service class" (presumably meaning EF).
Section 4.2.2 notes that peer-to-peer signaling (SIP) should use the "Low
latency Data service" (which is shown as AF2 in Figure 1). It isn't clear
where call signaling (SIP) should go, but it certainly needs to be a
different DSCP than the voice packets. 

Mike Pierce