Subject: Re: [ippm] WGLC for draft-ietf-ippm-delay-var-as.

From: Henk Uijterwaal <[email-masked]>
Date: Tue, 07 Oct 2008 10:39:21 +0200

Hi all,

> This message announces the WGLC for draft-ietf-ippm-delay-var-as-01
> 
> The draft has been discussed extensively in this group and appears
> to have support and be stable. We would like to start a Working Group Last
> Call in order to move it forward.
> 
> Please raise any remaining issues by October 6, 2008, 9:00 UTC.

This was yesterday, no issues were raised, so we'll move this draft forward.

Henk

> 
> A URL for the draft is:
> 
> <http://www.ietf.org/internet-drafts/draft-ietf-ippm-delay-var-as-01.txt>
>     
> 
> and the tools team also has a great page here:
> 
> <http://tools.ietf.org/wg/ippm/draft-ietf-ippm-delay-var-as>
> 
> 
> Matt & Henk
> 
> 

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 8 Oct 2008 10:10:50 +0200

Hello Henk,

sorry for being late, I couldn't make it earlier.

No objections to the draft as is (I'm aware that I had ample 
opportunity to object earlier).

Typos:

Section 4.2, last sentence of 2nd last textblock:

"However, approach has limitations that are..."
        ^^^^

Insert "this" or "the".

Section 6.2.2, first sentence

"If the path change is accompanied by loss, such that the are no..."
                                                      ^^^^
Replace "the" by "there".

7.3 Table, left column, last row

"Single Number SLS" 

That stands for "Service Level Specification" (or was SLA meant)?

Regards,

Ruediger

PS: Recognising that I was lazy in the past, a few content related remarks 
after the official message. 

Section 4.1 of  draft-ietf-ippm-delay-var-as states that
   'An example selection function given in [RFC3393] is "Consecutive
    Type-P packets within the specified interval."  This is exactly the
    function needed for IPDV.'

I'd be interested in learning whether Henk's and Matt's implementations 
apply this definition or another one. The question goes to all other 
implementiors too. The more natural selection function seems to be to 
evaluate pairs of consecutively received packets ignoring their 
sequence numbers. Draft-ietf-ippm-delay-var-as however works with an
IPDV definition assuming awareness of sequence numbers. I'd like to 
learn whether there are any implementations following the IPDV 
definition of draft-ietf-ippm-delay-var-as (see section 6.1).

The following statement reflects practical experience:

The implementation we work with only accounts for the absolute value 
of IPDV.

IPDV then is pretty sensible to fast changing queue levels, which 
you see during queue build up and prior to packet drops. It's a kind 
of seismographic curve you see then.

Looking at the definition, PDV is less sensible to queue build ups.

A final remark, also with some practical background: I think, a 
combination of PDV and IPDV is the most useful attempt. IPDV has merits 
in detecting reroutings and queue build ups, PDV may be more helpful 
in characterising a network during smooth operation. But having both 
seems to be best.

--end of message---

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henk Uijterwaal
Sent: Tuesday, October 07, 2008 10:39 AM
To: Henk Uijterwaal
Cc: IETF IPPM WG
Subject: Re: [ippm] WGLC for draft-ietf-ippm-delay-var-as.

Hi all,

Henk

---

From: Benoit Claise <[email-masked]>
Date: Thu, 09 Oct 2008 11:05:45 +0200

Geib,
> definition of draft-ietf-ippm-delay-var-as (see section 6.1).
The Cisco IP SLA feature follows the IPDV definition

Regards, Benoit.

---

From: Al Morton <[email-masked]>
Date: Thu, 09 Oct 2008 16:00:46 -0400

At 05:05 AM 10/9/2008, Benoit Claise wrote:
>>Rudiger wrote:

Hi Ruediger,

First, thanks for finding a few typos!

The specific case of packet loss in section 6.1 is also
mentioned in section 4.1 of RFC 3393:
http://tools.ietf.org/html/rfc3393#section-4.1
(don't confuse the selection function with the
conditioned statistics described here, they are
different processes).

In my experience, selection functions are primarily applied
at the Source, and the RFC 3393 definitions refer to index numbers
(or source sequence numbers).  A selection function like you describe
("pairs of consecutively received packets ignoring their
sequence numbers") is certainly possible, and it's important
to understand how different things can be when comparing
results from two different selection functions.
For example, some of your observations on re-routes may not hold for
the IPDV defined in the memo - lost packets and undefined pairs
are a key factor when trying to detect path changes with
"consecutive source packet" IPDV, as we explained.

The WIPM measurement system described in
http://tools.ietf.org/html/draft-ietf-ippm-implement-02
(expired I-D, but I'd still like to see this published as an
Informational RFC, even if it's not a formal part of the
standards track progress of the original RFCs)
implemented both IPDV and PDV as described in the memo.

thanks again, and regards,
Al

---

From: "Geib, Ruediger" <[email-masked]>
Date: Fri, 10 Oct 2008 08:51:28 +0200

Hi Al, 

[snipped larger parts]

[Al wrote]

[Ruediger]
Yes, respecting loss is one way to detect a reroute. The approach 
working with IPDV data only is described in 
draft-ietf-ippm-delay-var-as for the loss less path change (6.2.1). 
As soon as the IPDV measurement ignores losses, the method 
described there can always be applied.
I don't think that an IPDV selection funtion based on pairs of
packets in the sequence as they arrive is hard to implement. I 
further think, that this selection function has a couple of 
advantages over one respecting sequence numbers (and with that 
of course losses).

[Ruediger]
My impression is, if the aim is to learn the required dimensions of
de-jitter buffers a priori, PDV is the better choice. A network 
operator interested in learning more about the status of his 
network, may additionally use IPDV (with suitable selection and 
reporting functions).

[Ruediger]
Yes, maybe I felt the selection function your draft describes to be 
as strange as the you feel the one I describe to be...

Regards

Ruediger

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 10 Oct 2008 11:49:04 +0200

Hi Ruediger,

> definition of draft-ietf-ippm-delay-var-as (see section 6.1).

We use IPDV.

Henk