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

Thanks. 

I need to re-issue all the three documents anyway in order to align the references. I also need to address a different comment on the MIB document from another reviewer. I will probably submit a new set of I-Ds by tomorrow. 

Regards,

Dan



> -----Original Message-----
> From: Alan Clark [mailto:[email protected]]
> Sent: 03 January, 2005 6:01 PM
> To: Romascanu, Dan (Dan); [email protected]
> Subject: RE: [RMONMIB] I-D 
> ACTION:draft-ietf-rmonmib-raqmon-framework-08.txt
> 
> 
> Dan,
> 
> I think that with this edit incorporated into the framework 
> document and any
> associated references in the PDU and MIB documents updated 
> appropriately (if
> needed) then all my concerns will have been addressed.
> 
> Regards
> 
> Alan
> 
> 
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:[email protected]]
> Sent: Monday, January 03, 2005 8:10 AM
> To: Alan Clark; [email protected]
> Subject: RE: [RMONMIB] 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
> > >
> > >
> >
> >
> 
>