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

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: ippm-bounces@ietf.org [mailto:ippm-bounces@ietf.org] 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,

> 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
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm