At IETF 87 in Berlin, our team presented the Performance and Diagnostic Metrics (PDM) Option for the DOH Extension Header. This presentation, and the associated Draft, addressed the need for enhanced diagnostics and performance information in IPv6, as well as a recommended solution that would accomplish this.
Similar information on this topic was presented to both v6ops and 6man. There were several follow up issues and questions that we will now address on the Email list. We will be discussing our proposal with a number of other IETF groups (NTP, IPPM, LMAP) as well as RIPE NCC TTM. We will cross-post the results of our discussions on the appropriate lists. To summarize our proposal and the outstanding issues/questions:: 1. This Destination Option type is Optional and can be turned on/off independently at either end. 2. The field called Packet Sequence Number is similar to IPID in IPv4 and is primarily intended to ease and expedite diagnostics, particularly at end points. 3. The two Timestamp fields are primarily for network performance triage and metrics. These fields can also be utilized for: performance reporting; by security devices; and for any other functions requiring a highly granular time reference. 4. The 3 new fields can also be utilized together to further enhance network diagnostics and support, at any point or device in the network path. 5. The 4th field is open to be used by applications and platforms having "Special" performance or diagnostic needs (e.g. Gaming, commerce, etc.). 6. As pointed out by Joel after the presentation, having synchronized time sources in the devices being analyzed is critical for effective results when using the network performance (timestamps) features and functions. ANY performance monitoring/measurement solution will require this -- see, for example, RFC 2679 and RFC2681. We will discuss this issue with other groups to see how they have dealt with this problem. 7. Both the Packet Sequence number and the Timestamp fields are per "FLOW". After the presentation it was pointed out that this term was evidently not meaningful or specific enough. Some would use the words per "Session", per "Connection" or per "Socket". Regardless of the term applied, the 5 unique identifiers are IP address and port at each end point, plus the protocol (e.g. UDP, TCP, etc.). Hopefully that delineates what was referred to in the presentation as "Flow". 8. In the question and answer period of the presentation, it was suggested that this solution should work fine in private networks, but perhaps not on the Internet. It is our assertion that this solution should work on all networks, as long as the DOH Extension Header is passed end to end. Since Extension Headers are an intrinsic component of the IPv6 Architecture, we should be able to assume this to be true. If Extension Headers are not being passed along any given path (Internet or otherwise), then that is an issue/problem that is much bigger than this proposal and needs to be adequately addressed if IPv6 is to be successful. This is the area that we are exploring with other IETF groups. We hope to collaborate with them and incorporate their expertise and experience to build a solution which will be useful for the Internet as well as private networks. We feel that a simple and scalable way to provide accurate and timely diagnostics and performance measurement is what is needed to further the usability and promote the growth of the Internet as well as implementation of IPv6. If other issues or questions exist, relative to this proposal, we look forward to addressing them. The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies. Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
