One document matched: draft-tschofenig-cc-workshop-report-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
-->
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY I-D.ietf-avtcore-rtp-circuit-breakers SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avtcore-rtp-circuit-breakers.xml">
<!ENTITY RFC5405 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5405.xml">
<!ENTITY RFC2914 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2914.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="no" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-tschofenig-cc-workshop-report-00.txt" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Congestion Control Workshop Report">Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication</title>
<author fullname="Hannes Tschofenig" initials="H.T."
surname="Tschofenig">
<organization></organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<region></region>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Lars Eggert" initials="L.E."
surname="Eggert">
<organization></organization>
<address>
<postal>
<street>Sonnenallee 1</street>
<city>Kirchheim</city>
<region></region>
<code>85551</code>
<country>Germany</country>
</postal>
<phone>+49 151 12055791</phone>
<email>lars@netapp.com</email>
<uri>http://eggert.org/</uri>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Zaheduzzaman Sarker" initials="Z.S."
surname="Sarker">
<organization></organization>
<address>
<postal>
<street></street>
<city>Lulea</city>
<region></region>
<code>SE-971 28</code>
<country>Sweden</country>
</postal>
<phone>+46 10 717 37 43</phone>
<email>zaheduzzaman.sarker@ericsson.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!--
<author fullname="Bill Ver Steeg" initials="B.V.S."
surname="Ver Steeg">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<email>versteb@cisco.com</email>
</address>
</author>
-->
<date month="October" year="2012" />
<!-- <area>
Security
</area>-->
<keyword>Congestion Control</keyword> <keyword>RTCWeb</keyword> <keyword>Workshop</keyword> <keyword>Real-Time Communication</keyword>
<abstract>
<t>This document provides a summary of the IAB/IRTF Workshop on 'Congestion Control for Interactive Real-Time Communication', which took place in Vancouver, Canada, on July 28, 2012. The main goal of the workshop was to foster a discussion on congestion control mechanisms for interactive real-time communication. This report summarizes the discussions and lists the conclusions and recommendations to the Internet Engineering Task Force (IETF) community. The views and positions in this report are those of the workshop participants and do not necessarily reflect the views and positions of the authors, the Internet Architecture Board (IAB) or the Internet Research Task Force (IRTF).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>Any application that sends significant amounts of data over the Internet is expected to implement reasonable congestion control behavior. Although the specific mechanisms depend on the application or protocol, the motivations for congestion control are well understood and documented in RFC 2914 <xref target="RFC2914"/> and RFC 5405 <xref target="RFC5405"/>. The goals are:
<list style="numbers">
<t>Preventing congestion collapse.</t>
<t>Allowing multiple flows to share the network fairly.</t>
</list>
</t>
<t>
The Internet has been used for interactive real-time communication for decades, most of which is being transmitted using RTP over UDP, often over provisioned capacity and/or using only rudimentary congestion control mechanisms.</t>
<t>The development and upcoming widespread deployment of web-based real-time media communication - where RTP is used to and from web browsers to transmit audio, video and data - will likely result in substantial new Internet traffic. Due to the projected volume of this traffic, as well as the fact that it is more likely to use unprovisioned capacity, it is essential that it is transmitted with robust and effective congestion control mechanisms.</t>
<t>Designing congestion control mechanisms that perform well under a wide variety of traffic mixes and over network paths with widely varying characteristics is not easy. Prevention of congestion collapse can be achieved through "circuit breaker" mechanisms, but for media flows that are supposed to coexist with a user's other ongoing communication sessions, a congestion control mechanism that shares capacity fairly in the presence of a mix of TCP, UDP and other protocol flows is needed.</t>
<t>Many additional complications arise. Here are some examples:
<list style="numbers">
<t>Real-time interactive media sessions require low latencies, whereas streaming media can use large play-out buffers.</t>
<t>RTCP feedback about an RTP session typically arrives much less frequently than, for example, TCP ACKs for a given TCP connection. The RTP/RTCP control loop can lead to a longer reaction time.</t>
<t>Media codecs can usually only adjust their output rates in a much more coarse-grained fashion than, for example, TCP, and user experience suffers if encoding rates are switched too frequently. Codecs typically have a minimum sending rate as well.</t>
<t>Some bits of an encoded media stream are more important than others. For example, losing or dropping an I-frame of a video stream is more problematic than dropping a P-frame.</t>
<t>Ramping up the transmission rate can be problematic. Simply increasing the output rate of the codec without knowledge whether the network path can sustain transmission at the increased rate runs the danger of incurring a significant amount of packet loss that can cause playback artifacts.</t>
<t>A congestion control scheme for interactive media needs to handle bundles of interrelated flows (audio, video, data), in a way that accommodates the preferences of the application in the event of congestion.</t>
<t>The desire to provide a congestion control mechanism that can be efficiently implemented inside an application (e.g., a web server and a browser) imposes additional restrictions.</t>
<t>There are explicit congestion signals (such as ECN), and there are indirect indications of congestion (such as packet delay and loss). However, congestion is not the only source of these indirect signals. Care must be taken to account for each of these signals, particularly if various applications react on the same signals.</t>
<t>Network elements and end device operating systems often create buffers to better support TCP-based applications. These buffers introduce additional communication delay, which harms the small delay budget available for real-time applications.</t>
</list>
</t>
<t>Note that this document is a report on the proceedings of the workshop.
The views and positions documented in this report are those of the workshop
participants and do not necessarily reflect the views of the
authors.</t>
</section>
<section title="History and Current Status">
<t>The currently deployed RTP-based RTC systems use congestion control schemes that are ad hoc at best. As the Internet moves towards an RTCWeb standard for interoperable audio/video conferencing, it needs a standardized and most importantly effective mechanism for congestion control.</t>
<t>The most immediate need is for a control mechanism that balances a real-time flow
fairly among other competing traffic. For instance, under congested conditions, it
would be inappropriate to use far more bandwidth than flows from other applications
are using, particularly lasting gross over-utilization of
the network. Simple "circuit breaker" -style control mechanisms can prevent congestion collapse by
disabling a circuit that far exceeds a fair share and making the circuit remain disabled for some time.
But does not in any way enable concurrent flows to share available network capacity sensibly.</t>
<!--
<t>The most immediate need is for a circuit breaker mechanism that stops a flow when serious anomalies are detected, i.e., when it is using an order of magnitude more bandwidth than a TCP flow would use over the given path <xref target="I-D.ietf-avtcore-rtp-circuit-breakers"/>. This prevents the RTCWeb flows from causing long lasting gross over-utilization of the network. Circuit breakers can prevent congestion collapse if used correctly, i.e., if the circuit remains disabled for some time after the breaker triggers, but does not in any way enable concurrent flows to share available network capacity sensibly.</t>
-->
<t>Therefore, in addition to circuit breakers, more complete methods for media congestion control are needed. The focus of the workshop was on discussing ideas for these more complete congestion control methods.Note that the primary focus of the workshop is RTCWeb-style audio/video flows. The assumed underlying flows (in most attendees minds) were digital audio/video data encapsulated in RTP over UDP over IP. Most of the concepts presented at the workshop could be used with different media types over different transports, but this was the generally assumed baseline for discussions.</t>
</section>
<section title="Recommendations">
<t>The participants suggested to explore two complementary solution tracks, as described in the two sub-sections below.</t>
<section title="Changes to Network Infrastructure">
<t>Like for all other traffic on the network, better data plane infrastructure improves the perceived quality of the best-effort service the Internet provides for RTCWeb flows. The IETF has already developed several technologies that would be of immediate usefulness, if they were deployed. The workshop participants expressed the hope that due to the volume and importance of RTCWeb traffic, some of these technologies might finally see widespread use.</t>
<t>The first and by far most important improvement is traffic segregation, i.e., the ability to use different queues for different traffic types. Specifically jitter/delay sensitive and throughput maximizing protocols need to be in different queues. It is not possible for a single queue/AQM to be optimal for both.</t>
<t>Explicit Congestion Notification (ECN) allows routers along the end-to-end path to signal the onset of congestion and allows applications to respond early, avoiding losses and keep queue sizes short and therefore end-to-end delay low. ECN is implemented on some end system stacks and routers, but frequently not enabled.</t>
<t>Different mechanisms have been developed to facilitate traffic segregation. Differentiated services are one possibility in this space if applications start to mark outgoing traffic appropriately and routers would segregate traffic accordingly, browsers could more directly control the relative importance of their various flows, and avoid self-competition. Compared to ECN, however, DiffServ is far more difficult to deploy meaningfully end-to-end, especially given that DSCPs have no defined end-to-end meaning and packets can be re-marked. Quality-of-service (QoS) signaling together with resource reservation facilities would enable a fine-grained and flexible way to indicate resource needs to network elements but it is also by far the most heavyweight proposal, and unlikely to be viable in the global Internet.</t>
<t>However, any change to network infrastructure will take time particularly if the interest of the involved stakeholders is not aligned (as it is the case for network operators and over-the-top application providers). It is therefore imperative that RTCWeb congestion control provides adequate improvement in the absence of any of the aforementioned schemes.
</t>
</section>
<section title="Avoiding Self-Inflicted Queuing">
<t>This approach tries to ensure that the network does not get congested by focusing on the traffic sent by a single host independent of any changes to networks, as mentioned in the earlier chapter. A single congestion manager within the end host or the browser could already help to coordinate various congestion control activities and to ensure a more coordinated approach between different applications, and different flows.</t>
<t>The following activities were suggested during the workshop.</t>
<t> <list style="hanging">
<t hangText="Reacting to all Congestion Signals:"><vspace blankLines="1"/>
To initiate the congestion control process it is important to detect
congestion in the communication path. Congestion in the
comminication can be detected using either an explicit mechanism or
an implicit mechanism. The explicit mechanism involves direct
congestion signaling usually from the congested network node, such as
ECN. The ECN bits are set in the IP header by the network node
before it starts to drop the packets and gives end hosts to react to
the congestion. In case of implicite mechanism, a particular
characteristics or event in the network traffic can be inferred as a
congestion signal. For example, packet loss events or observed
delay increase or jitter in the communication path can be taken as an
implicit congestion signals. These measurements can also be made available
in a variety of different protocols, such as RTCP reports or transport
protocols. Communication endpoints can trigger congestion
control on the event of these phenomena. It is also possible to
correlate these events to detect congestion in the communication
path. The implicit and explicit signals can come in any sequence and
at any time during the ongoing media session. It is recommended to
react to all the possible implicit congestion signals, ideally from all
applications at the end host, to avoid self-
inflicted queues.</t>
<t hangText="Delay- and Loss-based Algorithms:"><vspace blankLines="1"/>
The main goal of designing a congestion control algorithm for
real-time conversational media is to achieve low latency. An
explicit signaling based congestion control algorithm perhaps is the
best fit for this purpose as the network nodes are directly involved
in the process. However, in case of absence of ECN support in the
end-to-end communication path delay based algorithms are needed where
the increased delay in the communication path is taken into account
as implicit congestion signal. While it is difficult to design
algorithms based on delay since many wireless networks show a wide delay
variation even in a non-congested network. The workshop participants
recommended that more research should be done to better understand
non-congestion related delay variation in the network. General consensus
among the workshop participants was that when latency-based techniques
were competing against loss-based techniques, the loss-based techniques
got all the bandwidth.</t>
<t hangText="Algorithm Evaluation:"><vspace blankLines="1"/>
The Internet consists of heterogeneous networks, which also includes
misconfigured, and unmanaged network nodes. Bandwidth and latency varies
a lot. Not only this, different services deployed using RTP/UDP have
different requirements in terms of media quality. A congestion control
algorithm needs to perform well not only in simulators but also in
today's Internet. To achieve this it is recommended to test the
algorithms with real-world loss and delay figures to be sure that the
desired audio/video rates are attainable using the proposed algorithms
for the desired services.</t>
<t hangText="Media Characteristics in Focus:"><vspace blankLines="1"/>
Interactive real-time voice and video data is inherently variable.
Usually the content of the media and service requirements dictate the
media coding. The codec may be bursty and not all frames are equally
important (e.g., I-frames are more important than P-frames). Thus,
codecs have limited room for adaptation. Congestion control for audio
and video codecs is therefore different to congestion control applied
for bulk transfers. The latter are allows buffering of media irrespective
to their content and more fine-grained control for a congestion control
algorithm. In the workshop these limitations were brought up and
the workshop participants recommended that a congestion controller needs
to be aware of these constraints. However, further investigation is
needed to decide what information needs to be exchanged between a codec
and the congestion manager.</t>
<t hangText="Startup Behaviour:"><vspace blankLines="1"/>
The startup media quality is very important for real-time interactive
application and for user-perceived application performance. The startup
behavior of these is also different to other traffic. By nature the
real-time interactive communication applications want to provide a
smooth user experience and maintain best media quality to ease the
interaction. While it may be desirable from a user experience point of
view to immediately start streaming video with high-definition quality
and audio of a wideband codec this will have impacts on the bandwidth of
the already ongoing flows. As such, it would be ideal to start slow enough
to avoid excessive congestion to other flows but fast enough to offer a
good user experience. The sweetspot, however, yet has to be found.</t>
</list>
</t>
<t>In addition, there were some discussions on how to make RTCWeb-style
flows fair to other RTCWeb-style flows, other TCP based flows, LEDBAT
flows, and other flows. This is a much more difficult problem than simply
making RTCWeb flows avoid congestion. Changing the way TCP is used in browsers
or other HTTP-based applications would already help, for example, by avoid
opening too many concurrent TCP connections, and improved interworking
with video streaming and file sharing software. The work on HTTP 2.0
with SPDY is already the step in the right direction since SPDY makes
makes use of a more aggressive form of multiplexing instead of opening
a larger number of TCP connections.</t>
</section>
</section>
<section anchor="Acknowledgments" title="Acknowledgments">
<t>We would like to thank the participants and the paper authors of the position
papers for their input.</t>
<t>Additionally, we would like to thank the following persons for their review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt Mathis, Mary Barnes</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>While two position papers focused on security congestion control security itself was not on the agenda of the workshop. As such, nothing beyond the material contained in those position papers can be reported.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References"> &RFC5405;
&RFC2914; </references>
<references title="Informative References"> &I-D.ietf-avtcore-rtp-circuit-breakers;
</references>
<section anchor="app-program" title="Program Committee">
<t>This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, and Hannes Tschofenig.</t>
</section>
<section anchor="app-material" title="Workshop Material">
<t>
<list style="symbols">
<t>Main Workshop Page: http://www.iab.org/activities/workshops/cc-workshop/</t>
<t>Position Papers: http://www.iab.org/activities/workshops/cc-workshop/papers/</t>
<t>Slides: http://www.iab.org/activities/workshops/cc-workshop/slides/</t>
</list>
</t>
</section>
<section anchor="app-papers" title="Accepted Position Papers">
<t>
<list style="numbers">
<t>"One control to rule them all" by Michael Welzl</t>
<t>"Congestion Avoidance Through Deterministic" by Pier Luca Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele Casagrande, Mirko Loghi, and Stefan Wieser</t>
<t>"Congestion Control in Real Time Media - Context" by Harald Alvestrand</t>
<t>"Improving the Interactive Real-Time Video Communication with Network Provided Congestion Notification" by ANM Zaheduzzaman Sarker, Ingemar Johansson</t>
<t>"Multiparty Requirements in Congestion Control for Real-Time Interactive Media" by Magnus Westerlund</t>
<t>"On Fairness, Delay and Signaling of Different Approaches to Real-time Congestion Control" by Stefan Holmer</t>
<t>"RTP Congestion Control and RTCWeb Application Feedback" by Ted Hardie</t>
<t>"Issues with Using Packet Delays and Inter-arrival Times for Inference of Internet Congestion" by Wesley M. Eddy</t>
<t>"Impact of TCP on Interactive Real-Time Communication" by Ilpo Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku Kojo, and Markus Isomaki</t>
<t>"Security Concerns For RTCWeb Congestion Control" by Dan York</t>
<t>"Vendors Considered Harmfull" by Cullen Jennings, Suhas Nandakumar, and Hein Phan</t>
<t>"Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong Pan</t>
<t>"Congestion Control for Interactive Real-Time Applications" by Sanjeev Mehrotra, and Jin Li</t>
<t>"There is No Magic Transport Wand" by John Leslie</t>
<t>"Towards Adaptive Congestion Management for Interactive Real-Time Communications" by Dirk Kutscher, and Miriam Kuehlewind</t>
<t>"Enlarge the pre-congestion spectrum usage?" by Xavier Marjou, and Emile Stephan</t>
<t>"Congestion control for users who don't have first-class internet access" by Maire Reavy</t>
<t>"Realtime Congestion Challenges" by Randell Jesup</t>
<t>"Congestion Control for Interactive Media: Control Loops & APIs" by Varun Singh, Joerg Ott, and Colin Perkins</t>
<t>"Some Notes on Threat Modelling Congestion Management" by Eric Rescorla</t>
<t>"Timely Detection of Lost Packets" by Ali C. Begen</t>
<t>"Congestion Control Considerations for Data Channels" by Michael Tuexen</t>
<t>"Position paper on CC for Interactive RT" by Matt Mathis</t>
<t>"Overall Considerations for Congestion Control" by M. Zanaty, B. VerSteeg, B. Christensen, D. Benham, A. Romanow</t>
<t>"Fairness Considerations for Congestion Control" by Mo Zanaty</t>
<t>"Media is not Data: The Meaning of Fairness for Competing Multimedia Flows" by Timothy B. Terriberry</t>
<t>"Thoughts on Real-Time Congestion Control" by Murari Sridharan</t>
<t>"Congestion Control for Interactive Real-Time Flows on Today's Internet" by Keith Winstein, Anirudh Sivaraman, and Hari Balakrishnan</t>
<t>"Congestion Control Principles for CoAP" by Carsten Bormann, Klaus Hartke</t>
<t>"Erasure Coding and Congestion Control for Interactive Real-Time Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel Lochin, Jerome Lacan, Vincent Roca</t>
<t>"Video Conferencing Specific Considerations for RTP Congestion Control" by Stephen Botzko and Mary Barnes</t>
<t>"The Internet is Broken, and How to Fix It" by Jim Gettys</t>
<t>"Deployment Considerations for Congestion Control in Real-Time Interactive Media Systems" by Jari Arkko</t>
</list>
</t>
</section>
<section anchor="app-participants" title="Workshop Participants">
<t>We would like to thank the following workshop participants for attending the workshop:
<list style="symbols">
<t>Mat Ford</t>
<t>Bernard Aboba</t>
<t>Alissa Cooper</t>
<t>Mary Barnes</t>
<t>Lars Eggert</t>
<t>Harald Alvestrand</t>
<t>Gonzalo Camarillo</t>
<t>Robert Sparks</t>
<t>Cullen Jennings</t>
<t>Dirk Kutscher</t>
<t>Carsten Bormann</t>
<t>Michael Welzl</t>
<t>Magnus Westerlund</t>
<t>Colin Perkins</t>
<t>Murari Sridharan</t>
<t>Klaus Hartke</t>
<t>Pier Luca Montessoro</t>
<t>Xavier Marjou</t>
<t>Vincent Roca</t>
<t>Wes Eddy</t>
<t>Ali C. Begen</t>
<t>Mo Zanaty</t>
<t>Jin Li</t>
<t>Dave Thaler</t>
<t>Bob Briscoe</t>
<t>Barry Leiba</t>
<t>Jari Arkko</t>
<t>Stewart Bryant</t>
<t>Martin Stiemerling</t>
<t>Russ Housley</t>
<t>Marc Blanchet</t>
<t>Zaheduzzaman Sarker</t>
<t>Xiaoqing Zhu</t>
<t>Randell Jesup</t>
<t>Eric Rescorla</t>
<t>Suhas Nandakumar</t>
<t>Hannes Tschofenig</t>
<t>Bill VerSteeg</t>
<t>Sean Turner</t>
<t>Keith Winstein</t>
<t>Jon Peterson</t>
<t>Maire Reavy</t>
<t>Michael Tuexen</t>
<t>Stefan Holmer</t>
<t>Joerg Ott</t>
<t>Timothy Terriberry</t>
<t>Benoit Claise</t>
<t>Ted Hardie</t>
<t>Stephen Botzko</t>
<t>Matt Mathis</t>
<t>David Benham</t>
<t>Jim Gettys</t>
<t>Spencer Dawkins</t>
<t>Sanjeev Mehrotra</t>
<t>Adrian Farrel</t>
<t>Greg White</t>
<t>Markku Kojo</t>
</list>
</t>
<t>We also had remote participants, namely
<list style="symbols">
<t>Emmanuel Lochin</t>
<t>Mark Handley</t>
<t>Anirudh Sivaraman</t>
<t>John Leslie</t>
<t>Varun Singh</t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 14:06:18 |