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

Alan,

Thanks for the edit proposal. It looks OK to me. 

Before I issue another version of the RAQMON drafts,  can you confirm that all your concerns have been addressed? I feel that we are very close to consensus that this round of documents with the agreed edits is appropriate for IESG submission level, but I would like to make sure. 

Regards,

Dan



> -----Original Message-----
> From: Alan Clark [mailto:[email protected]]
> Sent: 20 December, 2004 5:51 PM
> To: Romascanu, Dan (Dan); [email protected]
> Subject: RE: [RMONMIB] I-D 
> ACTION:draft-ietf-rmonmib-raqmon-framework-08.txt
> 
> 
> Dan
> 
> If you are updating the draft anyway to address the other 
> issues then this
> is easy to fix:-
> 
> 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
> >
> >
> 
>