RE: I-D ACTION:draft-ietf-rmonmib-raqmon-framework-08.txt

Alan,

I appreciate your contributions, but it would be good to avoid going back to sections that were discussed several times with a few comments at the detail level each time. This Working Group would like to wrap up the work on this standard. 

I am in agreement with you on a few of the details, I have corrected them and I am issuing a new Internet-Draft (draft-09). See below. 

I hope that this can be the last version and we can submit now the I-Ds to the IESG. 

Regards,

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of Alan Clark
> Sent: 19 December, 2004 8:46 PM
> To: [email protected]
> Subject: RE: [RMONMIB] I-D 
> ACTION:draft-ietf-rmonmib-raqmon-framework-08.txt
> 
> 
> Initial comments on the new draft
> 
> 5.13 Application Delay
> 
> This metric is still not well defined.  It is represented as being the
> difference between the network delay and the user experienced delay,
> describes two different values that could be measured - 
> neither of which
> meets the description of "capture all such delay parameters", 
> and provides
> no way to say what value is being reported.
> 
> For example - should an IP phone report sending delay or 
> receiving delay?

This section was discussed in detail two IETF meetings ago, and the current edit reflects these decisions. Your comments on draft 07 were accepted and included. The current text is clear about what needs to be included in a report from a host in both transmit and receive directions:

'- In the sending direction, application delay is defined as the sum of sample sequencing, accumulation and encoding delay.

- In the receiving direction application delay is calculated as the sum of delays associated to buffering, play-out, packet-sequencing, decoding associated with the receiving direction, if relevant. '

I do not believe that we can be more clear. 

> 
> 5.20 Cumulative Packet Loss
> 
> Definition still unclear.  Many packets can arrive late without being
> discarded, why should they be counted as lost? Suggest 
> wording such as...
> 
> "If a packet is discarded due to late arrival then it MUST be 
> counted as
> either lost or discarded but MUST NOT be counted as both."

I have included this in draft-09.

> 
> Also - packet loss should really be the difference between 
> what was sent and
> what was received, compensated for duplicate packets.  If the count is
> defined as "from the start of reception" then what if the 
> first N packets
> were lost .. according to this definition they would not be counted.

I changed 'beginning of reception' to 'beginning of the session'.

> 
> 5.22 Discards
> 
> If the RDS cannot tell the difference between discards and 
> lost packets then
> it >>MUST<< report only lost packets and MUST NOT report discards.

fixed. 

> 
> Regards
> 
> Alan
> 
> 
> _______________________________________________
> RMONMIB mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/rmonmib
>