[Gen-art] RE: [RMONMIB] Re: LC Review Assignment: RAQMON
"Romascanu, Dan \(Dan\)" <dromasca@avaya.com> Wed, 08 February 2006 15:41 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6rS3-0007Fx-8v; Wed, 08 Feb 2006 10:41:51 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6pfB-0000Ls-V5; Wed, 08 Feb 2006 08:47:19 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23697; Wed, 8 Feb 2006 08:45:36 -0500 (EST)
Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6prn-0005Bx-0p; Wed, 08 Feb 2006 09:00:19 -0500
Received: from tiere.net.avaya.com (tiere.net.avaya.com [198.152.12.100]) by nj300815-ier2.net.avaya.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id k18DhAIg022299; Wed, 8 Feb 2006 08:43:11 -0500
Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id k18Di5QH006828; Wed, 8 Feb 2006 08:44:06 -0500 (EST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Date: Wed, 08 Feb 2006 15:47:07 +0200
Message-ID: <AAB4B3D3CF0F454F98272CBE187FDE2F0A015738@is0004avexu1.global.avaya.com>
Thread-Topic: [RMONMIB] Re: LC Review Assignment: RAQMON
Thread-Index: AcYqcou6QRYr931mSkKXXnxd77GZIgCMxYPw
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: "Joel M. Halpern" <joel@stevecrocker.com>, gen-art@ietf.org
X-Scanner: InterScan AntiVirus for Sendmail
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 55503977758b6a5197d8a2b5141eae86
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Wed, 08 Feb 2006 10:41:49 -0500
Cc: ybkim@broadcom.com, bwijnen@lucent.com, rmonmib@ietf.org, "Siddiqui, Anwar A (Anwar)" <anwars@avaya.com>, eugene_golovinsky@bmc.com, mahfuz@research.panasonic.com
Subject: [Gen-art] RE: [RMONMIB] Re: LC Review Assignment: RAQMON
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
Sender: gen-art-bounces@ietf.org
Errors-To: gen-art-bounces@ietf.org
Hi Joel, Thank you for your review. Please find in-line my responses, including clarifications and proposals to address your comments. Regards, Dan > -----Original Message----- > From: rmonmib-bounces@ietf.org > [mailto:rmonmib-bounces@ietf.org] On Behalf Of Joel M. Halpern > Sent: Sunday, February 05, 2006 2:56 AM > To: gen-art@ietf.org > Cc: Romascanu, Dan (Dan); ybkim@broadcom.com; Siddiqui, Anwar > A (Anwar); eugene_golovinsky@bmc.com; rmonmib@ietf.org; > bwijnen@lucent.com; mahfuz@research.panasonic.com > Subject: [RMONMIB] Re: LC Review Assignment: RAQMON > > I was selected as General Area Review Team reviewer for this > specification (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > > Framework: > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- > framework-14.txt > This document is nearly ready for publication as a proposed standard. > (If I am confused about the congestion section, then it is ready for > publication.) > > Moderate: Congestion... > Has the congestion safety section been reviewed by a > transport area congestion expert? The AVT chairs participated in part of the discussions related to this document, but I am not sure whether this qualifies. > It seems to me that the description in section 3, bullet 1, > of the use of a constant Transmission rate ought to indicate > that the rate needs to be related to the expected peak number > of devices. (After all, the earlier text did talk about the > fan in problem.) Based on routing protocol experience, it > may also want to indicate that the timer for the constant > rate needs to be randomly jittered. What about: OLD: 1. Constant Transmission Rate: In a well-managed network a constant transmission rate policy (e.g. 1 RAQMON PDU per device every N seconds) will ensure congestion safety as devices are introduced into the network in a controlled manner. For example, in an enterprise network, IP Phones are added in a controlled manner and a constant transmission rate policy can be sufficient to ensure congestion safe operation. As a worst- case scenario, if the RDSs enforce an administrative policy where the maximum PDU transmission rate is no more than one RAQMON PDU every two minutes, a UDP based implementation can be as congestion safe as a TCP based implementation. Such policies can be enforced while configuring an RDS. NEW: 1. Constant Transmission Rate: In a well-managed network a constant transmission rate policy (e.g. 1 RAQMON PDU per device every N seconds) will ensure congestion safety as devices are introduced into the network in a controlled manner. For example, in an enterprise network, IP Phones are added in a controlled manner and a constant transmission rate policy can be sufficient to ensure congestion safe operation. The configured rate needs to be related to the expected peak number of devices. As a worst- case scenario, if the RDSs enforce an administrative policy where the maximum PDU transmission rate is no more than one RAQMON PDU every two minutes, a UDP based implementation can be as congestion safe as a TCP based implementation. Such policies can be enforced while configuring RDSs, and the timers for the constant rate need to be randomly jittered. > The title of section 3, bullet 2 (retransmission timers with back > offs) seems misleading. If I am reading the text right, the > actual technique is to send one message, and wait for a > response before sending another. What one might call "single > outstanding request." There is nothing in the text about > retransmissions and back-offs. (Although, such a technique > does require retransmissions, and such retransmissions must > be backed off. That is secondary to the core of the > technique, but ought to be mentioned.) Suggested fixes: OLD: Retransmission timers with back offs: This approach requires NEW: Single outstanding requests: This approach required and OLD: match. Since there's only one ball in play between any two players at any given time, most of the potential for congestion cascades is eliminated. For example if RAQMON PDUs are NEW: match. Since there's only one ball in play between any two players at any given time, most of the potential for congestion cascades is eliminated. For reliability and efficiency reasons this technique must include backed-off retransmissions. For example if RAQMON PDUs are > Section 3, bullet 3 is > about avoiding fragmentation. While that is a useful > technique, it does not seem to me that it is a congestion > avoidance technique. I would suggest no edit here. Bullet 3 is about limiting the transmission size wherever possible, which would have in our opinion the effect of lowering the probability of congestion happening. Of course, there are other good reasons to avoid fragmentation and restrict transmission size within the limits of the path MTU when known, but the argument still stands IMHO. > > Minor: In section 2.1.3, in describing how configuration > parameters can be accessed, it lists several ideas as if they > were implementable approaches. If we are going to call out > DHCP usage, don't we need to identify the DHCP option and > structure to use? If we are going to suggest using DNS, > don't we need to indicate how such configuration information > would appear in DNS? For LDAP, we would need a schema... > Having said that, I believe that the right answer is to > reword this list to indicate that Manual config is the only > defined method, a state that the remaining items are ideas > for future exploration. > (Unless you have a file format, a schema, a DHCP option, and > a DNS record structure up your sleeves already.) > And shouldn't the list include the MIB, which has the > right properties? Avoiding to mention configuration by SNMP and MIB objects is intentional, as the use of SNMP for configuration is not a popular practice nowadays. For the rest here is the suggested change: OLD: A RDS may use one or more of the following mechanisms to gain access to configuration parameters: - RDS acts as a trivial file transfer protocol (TFTP) client and downloads text scripts to read the parameters - RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client and gets RRC addressing information as a DHCP option - RDS acts as a DNS client and gets target collector information from a DNS Server - RDS acts as a LDAP Client and uses directory look-ups - RDS is manually configured using command line interface (CLI), Telephone User Interface (TUI) etc. NEW: A RDS may use manual configuration for the RDS configuration parameters using command line interface (CLI), Telephone User Interface (TUI) etc. One or more of the following mechanisms to gain access to configuration parameters can also be considered: - RDS acts as a trivial file transfer protocol (TFTP) client and downloads text scripts to read the parameters - RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client and gets RRC addressing information as a DHCP option - RDS acts as a DNS client and gets target collector information from a DNS Server - RDS acts as a LDAP Client and uses directory look-ups Identifying the DHCP option and structure to use, or defining the structure of the configuration information in DNS, or defining an LDAP schema could be explored as items of future work. > > Minor: DA, section 5.1. One line says that this parameter > MUST be sent in all RAQMON PDUs. The next lines say that > since it will remain constant, RDSs should avoid sending this > information too often. Which is it? Should it be in every > report, or should it be sent in only some reports, in order > to confirm that the state hasn't changed? (The same oddity > occurs with the RA.) The phrase This parameter MUST be sent in all RAQMON PDUs. will be taken out from both 5.1 and 5.2. > > Minor: Some of the "fraction" reporting items in section 5 > state that they are reported as a fixed point value with the > binary point at the left edge of the field (5.21). Most of > the items do not state the representation. I can understand > deferring the representation to the protocol / MIB. I can > understand including it here. But we ought to be consistent. > Given that the MIB uses "percent", and the PDU document gives > explicit encoding, probably this document should have no > format definition. Suggested change: OLD: The Packet loss in Fraction metric represents the packet loss as defined above, but expressed as a percentage of the total traffic over time. The fraction of application level packets from the source lost since the beginning of reception is expressed as a fixed point number with the binary point at the left edge of the field. NEW: The Packet loss in Fraction metric represents the packet loss as defined above, but expressed as a fraction of the total traffic over time. A similar change will be made in 5.23 > > Nit: The receiver of the report is not a source. Why does 5.2 > insist on calling it the "Receiver Source"? The title of 5.2 should be changed: OLD: 5.2 Receiver Source Address (RA) NEW: 5.2 Receiver Address (RA) > > Nit: In section 2.1.3, when describing ways of getting > configuration, the LDAP client method appears to be part of > the DNS method, rather than a separate method of its own. > Yes, the suggestion to amend 2.1.3 above > > PDU > http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon- > pdu-12.txt > This document is ready for publication as a Proposed Standard. > The few minor items should be considered if there is a need to revise the document. > Minor: In describing the T bits, it says "A value of zero is considered to be valid..." If I am reading this right, a value of 0 would be common, since many times there is > > no application specific information to add to the basic information. If it was intended that this count include the basic application information, then "that trail the > BASIC Part" would need to become "including the BASIC part." (And if it does not include the basic part, can we change "trail" to "follow"?) Suggested fix: OLD: trailer (T) : 3 bits - Total number of Application Specific Extensions that trail the BASIC Part of RAQMON PDU. A value of zero is considered to be valid as it may constitute a RAQMON NULL PDU. NEW: trailer (T) : 3 bits - Total number of Application Specific Extensions that follow the BASIC Part of RAQMON PDU. A value of zero is considered to be valid as many times there is no application specific information to add to the basic information. > Minor: The Packet Discard in Fraction field occurs in the packet before the Packet Loss in Fraction field. But discard is bit 31 and loss is bit 30 in the bits. And the > field descriptions after the bit table are in yet a different order. Is there a need for this variation? We shall swap the packet loss and packet discard bits and we will reorder the field description according to the order of the bits sequence numbers. > Minor: The WG probably considered it obvious, but I think there ought to be a short section that says roughly ~to use TCP to transport RAQMON PDUs, it is sufficient > to send the PDUs as the TCP data. As each PDU carries its length, the receiver can determine the PDU boundaries." I suggest to insert this between the second and third paragraph in Section 2.1 > Nit: "...both functional parts trail a field carrying ..." I am sure that there is a better word than "trail". Contain? Actually I believe that it should better be 'follow' instead of 'trail'. >MIB >http://www.ietf.org/internet-drafts/draft-ietf-rmonmib-raqmon-mib-11.tx t >This document is ready for publication as a Proposed Standard >Minor: The framework makes a point of distinguishing between >discarded packets and lost packets. The raqmonQos table does not >make such a distinction. Is there a reason for this? Probably this >would be dealt with by an extra sentence or two in section 4 >indicating the rationale for the particular selection of fields in the table. Actually there is such a sentence in section 4: - The raqmonQosTable contains historical information about QoS during sessions. The set of parameters represented in this table is more restricted, but it includes historical per RAQMON report information. >Nit: Was there no way to squeeze "priority" / "DSCP" (or at least >"pri") in the names of the raqmonParticipantSrcLayer2 (DestLayer2, >SrcLayer3, and DestLayer3) fields? The bits definition and the >description clause makes it clear what these are. But the naming >threw me for a bit. What about renaming those: raqmonParticipantSrcL2Priority raqmonParticipantDestL2Priority raqmonParticipantSrcDSCP raqmonParticipantDestDSCP _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
- [Gen-art] Re: LC Review Assignment: RAQMON Joel M. Halpern
- [Gen-art] RE: [RMONMIB] Re: LC Review Assignment:… Romascanu, Dan (Dan)
- [Gen-art] RE: [RMONMIB] Re: LC Review Assignment:… Joel M. Halpern
- [Gen-art] Re: [RMONMIB] Re: LC Review Assignment:… Andy Bierman