Subject: Re: [ippm] Comments on draft-cisco-sla-protocol-

From: "CIAVATTONE, LEN" <[email-masked]>
Date: Mon, 13 Feb 2012 16:45:06 +0000

I just wanted to comment that I am very interested in this draft. A number of years ago I worked with Cisco development to create an AT&T IPSLA-compatible software client which is still in large-scale use today. However, because that work was covered by NDA with Cisco we have always wanted to create a non-private version of the tool (and the switch to TWAMP is a big effort that can't always be utilized).

Leonard Ciavattone (Len)
AT&T Labs - IP Services
200 S. Laurel Avenue
Middletown, NJ 07748
Room: A2-4G06
Phone: (732) 420-1239

>X-Originating-IP: [144.151.223.11]
>X-Env-Sender: [email-masked]
>X-Msg-Ref: server-10.tower-120.messagelabs.com!1326682084!45741215!1
>X-Originating-IP: [12.22.58.30]
>X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor:
>   VHJ1c3RlZCBJUDogMTIuMjIuNTguMzAgPT4gMTI4MTUz\n
>X-StarScan-Version: 6.4.3; banners=-,-,-
>X-VirusChecked: Checked
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1;
>         t=1326682083; bh=nAu7iyzayO87R2QSXYXcMyXUDq2Gi78EQO4HOxehZsU=;
>         h=Message-Id:Date:To:From:In-Reply-To:References:Mime-Version:
>         Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:
>         List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender;
>         b=UvG0tCrn9lhtlAKe2bRqLpbpLwGZal9H5/4WO8W4K72jSn09wP/rtbD417/CmTkqa
>         QcL+DhC74V2h53s5UyQNOOT91/pHgx+SeMIYFUU/uMeoHL1GBxbQZgEbFDSwKo4JQe
>         CteeWOrI3g/JUxGhpbJFldRkmcLYU1IWgmm4v28s=
>X-Original-To: [email-masked]
>Delivered-To: [email-masked]
>X-Virus-Scanned: amavisd-new at amsl.com
>X-Spam-Flag: NO
>X-Spam-Score: -105.052
>X-Spam-Level:
>X-Spam-Status: No, score=-105.052 tagged_above=-999 required=5
>         tests=[AWL=-0.744, BAYES_05=-1.11, MSGID_FROM_MTA_HEADER=0.803,
>         RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
>X-Env-Sender: [email-masked]
>X-Msg-Ref: server-3.tower-119.messagelabs.com!1326682078!10726538!1
>X-Originating-IP: [144.160.20.145]
>X-StarScan-Version: 6.4.3; banners=-,-,-
>X-VirusChecked: Checked
>X-Originating-IP: [135.70.36.177]
>X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
>Date: Sun, 15 Jan 2012 21:47:55 -0500
>To: [email-masked], [email-masked], mchiba <[email-masked]>
>From: Al Morton <[email-masked]>
>X-RSA-Inspected: yes
>X-RSA-Classifications: public
>X-RSA-Action: allow
>Subject: [ippm] Comments on draft-cisco-sla-protocol- [was: Re: Wrapping up]
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.12
>List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
>List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www.ietf.org/mail-archive/web/ippm>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>,
>         <mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>
...
>
>Now that the IPR situation is clarified, I reviewed the draft.
>I encourage others to read this, it is a low-complexity alternative
>to TWAMP with the security features that TWAMP-Light lacks.
>
>My comments are below, I'm willing to work this further.
>Al
>
>In a couple of places, I saw configuration specifications
>in the protocol spec. These need to formalized if they
>are to be included, or removed (or identified more clearly as examples?)
>where they don't seem appropriate.
>
>Section 2:
>    The Measurement Phase forms the second phase and is comprised of a
>    sequence of Request/Response messages.  These messages may be
>    exchanged as often as required.  The number and frequency with which
>    messages are sent is controlled by configuration on the Sender
>    element.
>I suggest:
>    ... The number and frequency with which
>    messages are sent SHOULD be controlled by configuration on the Sender
>    element, along with the waiting time for a Control Response.
>
>
>2.2.  Measurement Phase
>
>    Upon receiving the Control Response message with the Status set to
>    Success, the second phase of the protocol, the Measurement Phase, is
>    initiated.  In all other cases when the Status is not success no
>    measurement traffic is initiated.  In the Measurement Phase the
>    Sender sends a stream of measurement messages.  The measurement
>    message stream consists of packets/frames that are spaced a
>    configured number of milliseconds apart.
>
>I suggest that the description of the measurement stream become an example:
>
>The measurement stream typically consists of packets/frames with a
>periodic inter-packet distribution [RFC3432] or pseudo-random
>distribution.
>
>Also, I suggest to make the following statement clear with words to
>this effect:
>
>The Sender need not wait for a Measurement Response packet to arrive
>before sending another Measurement Request packet, and in many cases it
>will not be possible in order to maintain the desired inter-packet
>distribution.
>
>2.1.1.1.  Command Header
>
>    The Command Header fields hold the following meaning:
>...
>    | --------- | --------- | --------------------------                |
>    | Send      | 64        | This field is set to the time the command |
>    | Timestamp |           | was sent and is updated for a response.   |
>    |           |           | This field MAY be used for secure         |
>    |           |           | environment.  SHOULD be updated for a     |
>    |           |           | response.  When not being used it MUST be |
>    |           |           | set to all 0's.  The format is as given   |
>    |           |           | in RFC1305                                |
>    +-----------+-----------+-------------------------------------------+
>
>There's some ambiguity in when a packet "was sent" when the timestamp
>must be inserted before sending takes place, of course. I suggest
>
>s/was sent/submitted to stack for transmission/
>
>or similar sentiment.
>
>That's what I have so far.
>
>
>
>
>_______________________________________________
>ippm mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ippm