WG RAQMON Internet-Drafts - PowerPoint PPT Presentation

About This Presentation
Title:

WG RAQMON Internet-Drafts

Description:

New Round of IETF Drafts as IETF-60 discussions. TCP transport ... then it is easier to state that a late packet may be classed as discarded or ... – PowerPoint PPT presentation

Number of Views:63
Avg rating:3.0/5.0
Slides: 11
Provided by: ava86
Learn more at: https://www.ietf.org
Category:

less

Transcript and Presenter's Notes

Title: WG RAQMON Internet-Drafts


1
WG RAQMON Internet-Drafts
  • RMON MIB WG Meeting
  • Washington, Nov. 11, 2004

2
New Round of IETF Drafts as IETF-60 discussions
  • TCP transport
  • Draft-ietf-rmonmib-raqmon-framework-07.txt
  • New metrics, existing metrics changes,
    clarifications
  • Draft-ietf-rmonmib-raqmon-pdu-07.txt
  • Add TCP transport
  • Fixes, changes, clarifications as per framework
    changes
  • Draft-ietf-rmonmib-raqmon-mib-05.txt
  • Fixes, changes, clarifications as per framework
    changes
  • Boilerplate changes for new Intellectual Property
    RFCs

3
Draft-ietf-rmonmib-raqmon-framework-07.txt
  • Framework and main RAQMON entities definition
  • Requirements
  • For RDS
  • RRC
  • Transport Protocol
  • RAQMON Data Model
  • Metrics changes, as per IETF-60 discussions
  • Rename / redefine / define new metrics for Round
    Trip End-to-End Network Delay, One Way End-to-End
    Network Delay, Application Delay, Inter-Arrival
    Jitter, IP Packet Delay Variation, Total Number
    of Application Packets Received, Total Number of
    Application Packets Sent, Total number of
    Application Octets Received, Total number of
    Application Octets Sent, Cumulative Application
    Packet Discards, Packet discards in Fraction,

4
RAQMON Data Model
  • Roundtrip End-to-End Network Delay
  • One way End-to-End Network Delay
  • Application Delay
  • Inter Arrival Jitter
  • IP Packet Delay Variation
  • Source Payload Type
  • Receiver Payload Type
  • Total number of Packets Received
  • Total number of Packets Sent
  • Total number of Octets Received
  • Total number of Octets Sent
  • Cumulative Packet Loss
  • Cumulative Packet Discard
  • Packet Loss in Fraction (in )
  • Packet Discard in Fraction (in )
  • Data Source Name (DN)
  • Receiver Name (RN)
  • Data Source Address (DA)
  • Receiver Address (RA)
  • Data Source Device Port used
  • Receiver Device Port used
  • Application Name

1
4
  • Session Setup Date/Time
  • Session Setup delay
  • Session duration
  • Session Setup Status

2
  • Source Layer 2 Priority
  • Destination Layer 2 Priority
  • Source Layer 3 Priority
  • Destination Layer 3 Priority

3
  • CPU utilization in Fraction (in )
  • Memory utilization in Fraction (in )

5
add other parameters by using extension of
Vendor Specific part of PDU
5
Comments and Open issues wrt. draft-ietf-rmonmib-r
aqmon-framework-07.txt
  • 5.7 Session Setup Date/ Time
  • Should be titled "Report Date/ Time" as it
    relates to the time at which the report was
    generated rather than the session setup
  • Resolve text inconsistency
  • Should this be in time zone independent format to
    permit easier correlation on large networks?
  • No, NTP format as per RFC 1305 is widely deployed
    operationally
  • 5.8 Session Setup Delay
  • "The Session Setup Delay metric reports the time
    taken from an origination request being initiated
    by an endpoint to the media path being
    established (or a call progress indication being
    received from the remote endpoint.)
  • accept
  • 5.11/ 5.12 End-to-End delay
  • Add a note to say that the packets used for
    measurement may be of a different type to those
    used for media (e.g. ICMP instead of RTP) and
    hence may differ in terms of route and queueing
    priority. This may result in measured delays
    being different to those experienced on the media
    path.
  • Accept work on clarification text
  • 5.12 - last paragraph
  • it would be simpler and more logical to say that
    RAQMON implementations should NOT derive one way
    delay by dividing rtd by 2 - just leave the
    parameter out if it is not known.
  • Accept

6
Comments and Open issues wrt. draft-ietf-rmonmib-r
aqmon-framework-07.txt (2)
  • 5.13 Application delay
  • "The network delay metrics described in sections
    5.11 and 5.12"......"The Application Delay
    metrics defined in this section are intended to
    capture additional elements of delay"
  • it is not clear if it is intended that the
    application delay includes BOTH encoding and
    buffer/decode delay, or are there two parameters?
  • Clarification receiving end delays
  • it is also confusing to talk about this as
    application delay, which should really be
    end-end. Call it "application endpoint delay",
    or add network delay and endpoint delay and call
    the sum "application delay
  • See above
  • 5.16 etc
  • Some IP endpoints separate signaling and media
    path system components. It would be more
    practical to say that applications packets MAY
    include signaling packets
  • Accepted
  • 5.20 Cumulative Packet Loss
  • Since there is now a packet discard count then it
    is easier to state that a late packet may be
    classed as discarded or lost - there should be no
    ambiguity
  • Clarify avoid double counting
  • Mandatory use of SNMP
  • Clarified on list with the commenter
  • RDS may use one of the transport
  • RRC MUST support both

7
Draft-ietf-rmonmib-raqmon-pdu-07.txt
  • Combined tcpsip I-D with the RAQMON PDU draft
  • Draft renamed to reflect multiple transport
  • Has two options supported in PDU Draft
  • Native TCP
  • SNMP
  • RDS can implement either one, but RRC MUST
    implement both
  • Syntactical re-arrangement of PDU to accommodate
    4 New Parameters
  • End to End Delay Split
  • Application/End Device Delay
  • Network Delay (RTT OWD)
  • Cumulative Packet Discards
  • Discards (in )
  • Corrections to the MIB as per metrics changes
  • change template for new IPR requirements
  • IANA considerations

8
PDU Structure
Shortened Report Type
Re-Arrangement 256 Sub sessions
..
..
Extensions
9
Draft-ietf-rmonmib-raqmon-mib-04.txt
  • change syntax of objects in raqmonParticipantTable
    to Integer32 to add values of -1 in cases when
    the collector did not receive any report on the
    specific metrics
  • change object names to align with
    RAQMON-FRAMEWORK
  • added objects in raqmonParticpantTable to cover
    all metrics in RAQMON-FRAMEWORK
  • added raqmonRDSTimeout object to control the
    timeout for reports in collectors
  • change template for new IPR requirements
  • aligned REFERENCE clauses with new numbering in
    RAQMON-FRAMEWORK
  • added new mandatory IANA considerations section

10
Conclusions and Recommendations
  • WGLC comments editorial in nature
  • Comments resolution includes clarifications in
    the framework, no impact on PDU and MIB documents
  • We seem to be converging on content and quality
  • Its been taking so long (11th IETF meeting!)
  • Recommend to forward to the IESG, with the edits
    as per decisions of this meeting
Write a Comment
User Comments (0)
About PowerShow.com