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

Suggested replacement text for section on Application Delay

Alan



OLD TEXT

 - 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.

   << PROBLEM - two defns of application delay>>

   It is easy to recognize that applications running on an IP device can
   experience same network delay but have different application
   associated delay values and hence the user experience associated to
   specific applications will vary while the network delay value remains
   same for both the applications.

   Having network delay and application delay measurements available, a
   management application can represent the delay experienced by the end
   user at the application level as a sum of network delay and the
   appropriate application delay. However the specification of such a
   management application is outside the scope of RAQMON specification

   << PROBLEM - does not define which application delay, does not say
      sum of delays >>

PROPOSED NEW TEXT

 - the sending end contribution to application delay is defined as the sum
   of sample sequencing, accumulation and encoding delay.

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

   the endpoint application delay is defined as the sum of the receiving
   and sending contributions to delay measured or estimated within the
   endpoint that is generating this report.

   It is easy to recognize that applications running on an IP device can
   experience same network delay but have different application
   associated delay values and hence the user experience associated to
   specific applications may vary while the network delay value remains
   same for both the applications.

   Having network delay and application delay measurements available, a
   management application can represent the delay experienced by the end
   user at the application level as a sum of network delay and the
   application delays reported from the endpoints. However the
   specification of such a management application is outside the scope
   of RAQMON specification

Regards

Alan


-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email protected]]
Sent: Monday, December 20, 2004 10:40 AM
To: Alan Clark; [email protected]
Subject: RE: [RMONMIB] I-D
ACTION:draft-ietf-rmonmib-raqmon-framework-08.txt


Alan,

Oh, I see - I thought this was clear. We are referring to the sum of both
sending and receiving, same approach as RC 3611 has taken for VoIP. I
believe this is obvious from the fact that this is the information available
at one end, and because we are detailing what happens on the sending
direction and receiving direction. If you believe that the word 'sum' is
missing it's fine with me to add it in a coming iteration, but I do not
believe this is worth a new version of the document. Obsessive editing does
not help at this stage, let us focus on deciding if the documents are 'good
enough' to be forwarded to the IESG.

Thanks and Regards,

Dan



> -----Original Message-----
> From: Alan Clark [mailto:[email protected]]
> Sent: 20 December, 2004 5:16 PM
> To: Romascanu, Dan (Dan); [email protected]
> Subject: RE: [RMONMIB] 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
>
>


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