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

Geib,
> 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 Cisco IP SLA feature follows the IPDV definition

Regards, Benoit.
> 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
>>
>>
>>     
>
>
>