Who is the man behind the recent development of a communications test breakthrough? That’s Barry Constantine, big contributor to this big score for JDSU’s communications test and measurement business segment. See here. And, be sure to view video below.
He was the lead in developing the test methodology, known as RFC 6349, in collaboration with two major global network operators. The method was recently published by the Internet Engineering Task Force (IETF), a group dedicated to developing and promoting Internet standards. It establishes a “repeatable methodology for measuring end- to-end TCP Throughput managed IP networks.”
What that really means is it helps to significantly improve quality – it measures the end user quality of experience when uploading and downloading video and other high-bandwidth content over the Internet.
We got caught up with Barry recently to talk about his view of this milestone, the process, how rewarding the experience was to be a part of such a powerful event for JDSU. Barry, who not only has 18 years experience in the communications industry and seven years with defense avionics electronics design but also holds a MSEE from the University of Maryland, had the following to say:
How did JDSU get involved in the IETF, the organization the sets forth recommended methodologies that helps define the future of next-generation communications services?
JDSU became a member of the working group by taking an interest in the activity of the IETF, following developments in the communications industry that IETF helped to initiate, and attended meetings. To be a part of developing the RFC 6348 methodology, the genesis is we first submitted what is called a “personal contribution” at an Anaheim meeting in March 2010 which was voted on by the working group (IP Performance Metrics or ippm). The JDSU submission was accepted as an active ippm working group document at this meeting.
What were some of the challenges and/or advantages throughout the process?
- Technical challenges: TCP is a “wild beast” in the network and it is difficult (some thought impossible) to nail down best practices to specify and measure TCP throughput. Developing a practical methodology but not oversimplifying TCP and all of its complexity was the key challenge. The #1 goal of RFC 6349 was to nail down a methodology that could be used by the masses, just not those with PHDs.
- Representing the test side of the industry: This was actually an advantage since I was able to test the methodology with our state-of-the-art tools and lab, and also field test the methodology along the way to prove it was accurate (and desired by network providers).
- Collaborating with two other service providers – ensuring objectivity: This again was a huge advantage since together we were a blend of experience and expertise which helped solidify the work as both practical and accurate.
What are some of the personal and professional rewarding aspects of being a part of developing this method? What makes you proud?
There are a few that stand out. Meeting and working with IETF experts (outside the author ring) who actually developed TCP stacks and recognized world experts in the TCP arena. From the first draft to the final, the improvement to the RFC was dramatic because of the massive influx of important review and comments that came from this team of reviewers. Also, it was a really fantastic moment when we got to the final version (draft-13!) and got to hear the TCP experts say “this is good.” In addition to external interfaces with the co-authors and many IETF experts, I am very proud of the JDSU engineering team. It was their commitment to developing a state of the art TCP test capability that was the enabler for the RFC.
Was this a global effort? Where did you and the team meet and how often? How long did this process take?
The co-authors, major service providers, were based in Montreal, Canada, Britain and Germany. Many reviews took place through email exchanges. Formal IETF meetings occurred every four months. There were critical reviewers as well from other European countries. The timeline from start to finish: the IETF submission was accepted in March 2010 – and, in August 2011, the RFC methodology was published.
A core to JDSU’s brand is that we are close collaborators with our customers, partners, key stakeholders, and that we are innovation experts – with that in mind, what does it mean, what’s the significance of JDSU being a part of this method?
JDSU was the lead author on this document and originators of the need for this type of solution. Lack of TCP methodology is a huge gap in customer satisfaction once services are activated. As we developed this technique, we shared the work’s progress with many (many!) network providers and the response was always “the industry desperately needs to close this gap.” So we feel that RFC 6349 will be a major step forward to help providers and business customers “speak the same language” and enable service activation to be “right the first time.”
Editor’s note: JDSU has integrated the methodology in its TrueSpeed™ automated TCP test solution, available for the JDSU Multi-Services Application Module (MSAM) on both the JDSU T-BERD/MTS-6000A and JDSU T-BERD/MTS-8000 . Click below to see Barry discuss JDSU TrueSpeed.
Start Video Code
End Video Code - Breakthrough Technology: JDSU Behind the Scenes