A standard or not a standard? A report from TUM being at IETF 87.
Each year the IETF (Internet Engineering Task Force) has meetings on multiple continents including Europe. IETF 87 was in Berlin July 28- August 2, 2013. A representative from TUM presented a proposal for standardization at the IRTF part of the IETF meeting. Now, what is the IRTF?
One way to generate standards is to have stakeholders, usually representatives from Industry, meet and agree on a standard for a certain technology to be used in a few years, e.g. cellular networks in Europe in 2020. In case of such approaches to standardization, the representatives agree on a usually long specification for the technology to be used in the future. It is not necessary that there are already working implementations, but it is usually clear that it is just a question of cost if companies will manage to build equipment and software that fulfills the specification. In such situations there is also no question if the standard is needed.
IETF works a bit differently. While it may also work on larger standards, most work is on standards for a specific and tightly focused problem, often part of a larger set of standards specifying different aspects of an Internet protocol. Not all proposals for standards will be accepted and not all work will end in a standard. Work is done by a group of volunteers from Industry and Academia, and if enough agree that something is important and can be agreed to (rough consensus), then it may become a standard. In the process documents are produced, discussed and given enough interest people may start to implement software.
IRTF stands for Internet Research Task Force. So, it is not directly working on the development of standards, rather it tries to answer the question from earlier if there is a need for a standard. Such a need may arise due to new developments in practice and research, or simply due to a new idea that in the long run might become interesting for standardization.
TUM is active in the network management section of the IRTF and the IETF. TUM’s proposal at IETF 87 was to consider if quality of service extensions for IPFIX would be needed. IPFIX is used to monitor flows in a network and Internet routers send their data via IPFIX to an analyzer or management tool. This kind of measurement is called passive measurement and one of its nice properties is that it is non-intrusive. It does not interfere with the observed traffic and network operation. So, what is now the proposal? Today’s Internet is full of so-called asymmetric paths. The packet from A to B may traverse other Internet routers than the reply from B to A. Passive measurement, however, may need to see request and reply pairs. As a consequence, the proposal is to extend IPFIX so that routers can report packet observations that match certain criteria. Given both routers report to the analyzer, it can infer the request-reply pair and determine the current service quality (what causes delays, do we have buffer bloat). This is useful not only for quality of service measurement, but also to find sources of errors that lead to bad performance. Other use-cases are possible.
What will come out of it? Well, this is completely open.