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

Dan

I am trying to keep my comments limited to making sure that the issues
discussed and agreed at the WG meeting were properly addressed in the new
draft, and think that this is the case.

With regard to the application delay, the point I'm making is as follows:-

Say that some form of interactive application has a sending end (A)
application delay of Tapp(A,S) and the associated receiving end (B)
application delay is Tapp(B,R).  In some cases there may be traffic in the
reverse direction and hence there would be an equivalent Tapp(B,S) and
Tapp(A,R).  In addition there is a network delay Trtd.

The time taken for an application "event" to go from A to B and for some
response to go back to A (has to be A-B-A or B-A-B interaction otherwise the
participants would be unaware of delay) is

Tapp(A,S) + Tapp(B,R) + (user response time at B) + Tapp(B,S) + Tapp(A,R) +
Trtd

B does not know the values of Tapp(A,S) or Tapp(A,R) but should know
Tapp(B,S) and Tapp(B,R) and can report these.  The central collection system
can obtain the Tapp(x,S/R) from both ends and the Trtd value from either end
and hence estimate the overall application delay.

If RAQMON only reports ONE of Tapp(x,S) and Tapp(x,R) and does not identify
which is being reported then the central collection system only has half the
information needed to estimate user perceived delay!!!

This is exactly why RFC3611 reports "end system delay" as the sum of the
receiving and sending application delay from one endpoint.  If you add the
end system delays from both ends to the round trip delay then you have the
application delay.

To fix this - the RAQMON framework needs to EITHER report BOTH sending and
receiving delays for the reporting endpoint OR needs to report end system
delay as defined in RFC3611.

Regards

Alan




-----Original Message-----
From: [email protected] [mailto:[email protected]]On
Behalf Of Romascanu, Dan (Dan)
Sent: Monday, December 20, 2004 3:29 AM
To: Alan Clark; [email protected]
Subject: RE: [RMONMIB] 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
>

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