One document matched: draft-hayes-rmcat-sbd-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- 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 RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3550 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC4585 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY RFC5124 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY RFC5481 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5481.xml">
<!ENTITY RFC6817 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6817.xml">
<!ENTITY RFC1323 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1323.xml">
<!ENTITY I-D.welzl-rmcat-coupled-cc SYSTEM
"http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.draft-welzl-rmcat-coupled-cc-03.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="yes" ?>
<!-- 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="exp" docName="draft-hayes-rmcat-sbd-00" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
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="SBD for CCC with RTP Media">
Shared Bottleneck Detection for Coupled Congestion Control for
RTP Media.
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="David Hayes" initials="D.A." role="editor"
surname="Hayes">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<city>Oslo</city>
<region></region>
<code>N-0316</code>
<country>Norway</country>
</postal>
<phone>+47 2284 5566</phone>
<email>davihay@ifi.uio.no</email>
</address>
</author>
<author fullname="Simone Ferlin" initials="S."
surname="Ferlin">
<organization>Simula Research Laboratory</organization>
<address>
<postal>
<street>P.O.Box 134</street>
<city>Lysaker</city>
<region></region>
<code>1325</code>
<country>Norway</country>
</postal>
<phone>+47 4072 0702</phone>
<email>ferlin@simula.no</email>
</address>
</author>
<author fullname="Michael Welzl" initials="M."
surname="Welzl">
<organization>University of Oslo</organization>
<address>
<postal>
<street>PO Box 1080 Blindern</street>
<city>Oslo</city>
<region></region>
<code>N-0316</code>
<country>Norway</country>
</postal>
<phone>+47 2285 2420</phone>
<email>michawe@ifi.uio.no</email>
</address>
</author>
<date month="October" year="2014" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>RTP Media Congestion Avoidance Techniques</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>SBD</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>This document describes a mechanism to detect whether
end-to-end data flows
share a common bottleneck. It relies on summary statistics that are calculated by
a data receiver based on continuous measurements and regularly fed to a grouping algorithm that
runs wherever the knowledge is needed. This mechanism complements the coupled congestion
control mechanism in draft-welzl-rmcat-coupled-cc.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>In the Internet, it is not normally known if flows (e.g., TCP connections or UDP data streams)
traverse the same bottlenecks. Even flows that have the same sender and receiver may take
different paths and share a bottleneck or not. Flows that share a bottleneck link usually
compete with one another for their share of the capacity. This competition has the potential
to increase packet loss and delays. This is especially relevant for interactive applications
that communicate simultaneously with multiple peers (such as multi-party video). For RTP
media applications such as RTCWEB, <xref target="I-D.welzl-rmcat-coupled-cc"></xref> describes
a scheme that combines
the congestion controllers of flows in order to honor their priorities and avoid unnecessary
packet loss as well as delay.
This mechanism relies on some form of Shared Bottleneck Detection (SBD); here, a
measurement-based SBD approach is described.</t>
<section title="The signals">
<t>The current Internet is unable to explicitly inform
endpoints as to which flows share bottlenecks, so endpoints
need to infer this from packet loss and packet delay.</t>
<section title="Packet Loss">
<t>Packet loss is often a relatively rare
signal. Therefore, on its own it is of limited use for
SBD, however, it is a valuable supplementary measure when
it is more prevalent.</t>
</section>
<section title="Packet Delay">
<t>End-to-end delay measurements include noise from every
device along the path in addition to the delay
perturbation at the bottleneck device. The noise is
often significantly increased if the round-trip time is used. The
cleanest signal is obtained by using One-Way-Delay
(OWD).</t>
<t>Measuring absolute OWD is difficult since it
requires both the sender and receiver clocks to be
synchronised. However, since the statistics being
collected are relative to the mean OWD, a relative OWD
measurement is sufficient. Clock drift is not usually
significant over the time intervals used by this SBD
mechanism (see <xref target="RFC6817"/> A.2 for a
discussion on clock drift and OWD measurements).</t>
<t>Each packet arriving at the bottleneck buffer may
experience very different queue lengths, and therefore
waiting times. A single OWD sample does therefore not
characterize the actual OWD of a path well. However,
multiple OWD measurements do reflect the distribution of
delays experienced at the bottleneck.</t>
</section>
<section title="Path Lag">
<t>Flows that share a common bottleneck may traverse
different paths, and these paths will often have different
base delays. This makes it difficult to correlate changes
in delay or loss. This technique uses the long term shape
of the delay distribution as a base for comparison to
counter this.</t>
</section>
</section>
</section>
<section anchor="Definitions" title="Definitions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
<t>Acronyms used in this document:
<list hangIndent="10" style="hanging">
<t hangText=" OWD --"> One Way Delay</t>
<t hangText=" RTT --"> Round Trip Time</t>
<t hangText=" SBD --"> Shared Bottleneck Detection</t>
</list></t>
<t>Conventions used in this document:
<list hangIndent="16" style="hanging">
<t hangText=" T --"> the base time interval over which measurements
are made.</t>
<t hangText=" N --"> the number of base time, T, intervals
used in some calculations.</t>
<t hangText=" sum_T(...) --"> summation of all the
measurements of the variable in parentheses taken over the
interval T</t>
<t hangText=" sum_N(...) --"> summation of N terms of the variable in parentheses</t>
<t hangText=" sum_NT(...) --"> summation of all
measurements taken over the interval N*T</t>
<t hangText=" E_T(...) --"> the expectation or mean of the
measurements of the variable in parentheses over T</t>
<t hangText=" E_N(...) --"> The expectation or mean of the last N values of
the variable in parentheses</t>
<t hangText=" max_T(...) --"> the maximum recorded measurement
of the variable in parentheses taken over the interval T</t>
<t hangText=" p_l, p_f, p_pdf, p_s, p_d, p_v --"> various
thresholds used in the mechanism.</t>
</list></t>
<section anchor="lcn-parameters" title="Parameter Values">
<t>Reference <xref target="Hayes-LCN14"/> uses T=350ms,
N=50, p_l = 0.1,
p_f = 0.2, p_pdf = 0.3, p_s = p_d = p_v = 0.2. These are
values that seem to work well over a wide range of practical
Internet conditions.</t>
</section>
</section>
<section anchor="Mechanism" title="Mechanism">
<t>The mechanism described in this document is based on the
observation that the delay measurements of flows that share a
common bottleneck have similar shape characteristics. The
shape of these characteristics are described using 3 key summary
statistics:
<list style="hanging">
<t>variance (estimate PDV, see <xref target="sbd_varest"/>)</t>
<t>skewness (estimate skewest, see <xref target="sbd_skewest"/>)</t>
<t>oscillation (estimate freqest, see <xref target="sbd_freqest"/>)</t>
</list></t>
<t>Summary statistics help to address both the noise and the
path lag problems by describing the general shape over a
relatively long period of time. This is sufficient for their
application in coupled congestion control for RTP Media. They
can be signalled from a receiver, which measures the OWD and calculates
the summary statistics, to a sender, which is the entity that is transmitting
the media stream. An RTP Media device may
be both a sender and a receiver. SBD can be performed at both the
Sender and the Receiver.</t>
<figure align="center" anchor="sbd-topo">
<!-- <preamble>Preamble text - can be omitted or empty.</preamble> -->
<artwork align="left"><![CDATA[
+----+
| H2 |
+----+
|
| L2
|
+----+ L1 | L3 +----+
| H1 |------|------| H3 |
+----+ +----+
]]></artwork>
<postamble>A network with 3 hosts (H1, H2, H3) and 3 links (L1, L2, L3).</postamble>
</figure>
<t>In <xref target="sbd-topo" />, there are two possible cases
for shared bottleneck detection: a sender-based and a
receiver-based case.
<list style="numbers">
<t>
Sender-based: consider a situation where host H1 sends media
streams to hosts H2 and H3, and L1 is a shared bottleneck.
H2 and H3 measure the OWD and calculate summary statistics,
which they send to H1 every T. H1, having this knowledge,
can determine the shared bottleneck and accordingly control
the send rates.</t>
<t>Receiver-based: consider that H2 is also sending media to
H3, and L3 is a shared bottleneck. If H3 sends summary
statistics to H1 and H2, neither H1 nor H2 alone obtain
enough knowledge to detect this shared bottleneck; H3 can
however determine it by combining the summary statistics
related to H1 and H2, respectively. This case is applicable
when send rates are controlled by the receiver; then, the
signal from H3 to the senders contains the sending rate.</t>
</list></t>
<t>A discussion of the required signaling for the receiver-based
case is beyond the scope of this document. For the sender-based
case, the messages and their data format will be defined here in
future versions of this document. We envision that an
initialization message from the sender to the receiver could
specify which key metrics are requested out of a possibly
extensible set (losscnt, PDV, skewest, freqest).
The grouping algorithm described in this
document requires all four of these metrics, and receivers MUST be
able to provide them,
but future algorithms may be able to exploit other metrics
(e.g. metrics based on explicit network signals).
Moreover, the initialization message could
specify T, N, and the necessary resolution and precision (number of bits
per field).
</t>
<section anchor="sbd-metrics" title="Key metrics and their calculation">
<t>Measurements are calculated over a base interval,
T. T should be long enough to provide enough samples
for a good estimate of skewness, but short enough so that
a measure of the oscillation can be made from N of these
estimates. Reference <xref target="Hayes-LCN14"/>
uses T = 350ms and N = 50,
which are values that seem to work well over a wide range
of practical Internet conditions.</t>
<section title="Mean delay">
<t>The mean delay is not a useful signal for comparisons,
however, it is a base measure for the 3 summary
statistics. The mean delay, E_T(OWD), is the average one
way delay measured over T.</t>
<?rfc needLines="6" ?>
<t>To facilitate the other calculations, the last N
E_T(OWD) values will need to be stored in a cyclic buffer
along with the moving
average of E_T(OWD):
<list style="hanging">
<t>E_N(E_T(OWD)) = sum_N(E_T(OWD)) / N</t>
</list>
</t>
</section>
<section anchor="sbd_skewest" title="Skewness Estimate">
<t>Skewness is difficult to calculate efficiently and
accurately. Ideally it should be calculated over the entire
measurement for the entire period (N * T), however this
would require storing every delay measurement over the
period. Instead, an estimate is made over T using the
previous calculation of E_T(OWD). Comparisons are made
using the mean of N skew estimates.</t>
<t>The skewness is estimated using two counters, counting
the number of one way delay samples above and below the
mean:
<list style="hanging">
<t> skewest = (sum_T(OWD < E_T(OWD)) - sum_T(OWD > E_T(OWD)))/num(OWD)
<list style="hanging">
<t> where
<list style="hanging">
<t>if (OWD < E_T(OWD)) 1 else 0</t>
<t>if (OWD > E_T(OWD)) 1 else 0</t>
</list></t>
<t>skewest is a number between -1 and 1</t>
</list></t>
<t>E_N(skewest) = sum_N(skewest) /N</t>
</list>
For implementation ease, E_T(OWD) is the mean delay of the previous
T interval. Care must be taken when implementing the
comparisons to ensure that rounding does not bias
skewest.</t>
</section>
<section anchor="sbd_varest" title="Variance Estimate">
<t>Packet Delay Variation (PDV) (<xref target="RFC5481"/>
and <xref target="ITU-Y1540"/>
is used as an estimator of
the variance of the delay signal. We define PDV
as follows:
<list style="hanging">
<t>PDV = (max(OWD) - E_T(OWD))</t>
<t>E_N(PDV) = sum_N(PDV) /N</t>
</list>
This modifies PDV as outlined in <xref target="RFC5481"/>
to provide a summary statistic version that best
aids the grouping decisions of the algorithm (see <xref
target="Hayes-LCN14"/> section IVB).</t>
</section>
<section anchor="sbd_freqest" title="Oscilation Estimate">
<t>An estimate of the low frequency oscillation of the delay
signal is calculated by counting and normalising the significant mean,
E_T(OWD), crossings of E_N(E_T(OWD)):
<list style="hanging">
<t> freqest = number_of_crossings / N</t>
<t> Where
<list style="hanging">
<t> we define a significant mean crossing as a crossing
that extends p_v * E_N(PDV) from E_N(E_T(OWD)). In our
experiments we have found that p_v = 0.2 is a good
value.</t>
</list></t>
</list>
Freqest is a number between 0 and 1. Freqest and
can be approximated incrementally as follows:
<list style="hanging">
<t> With each new calculation of E_T(OWD) a decision is
made as to whether this value of E_T(OWD) significantly
crosses the current long term mean, E_N(E_T(OWD), with respect to
the previous significant mean crossing.</t>
<t>A cyclic buffer, last_N_crossings, records a 1 if there is a significant
mean crossing, otherwise a 0.</t>
<t>The counter, number_of_crossings, is incremented when there
is a significant mean crossing and subtracted from when a
non zero value is removed from the last_N_crossings.</t>
</list>
This approximation of freqest was not used in <xref
target="Hayes-LCN14"/>, which calculated freqest every T
using the current E_N(E_T(OWD)). Our tests show that
this approximation of freqest yields results that are almost
identical to when the full calculation is performed every T.</t>
</section>
<section title="Packet loss">
<t>The proportion of packets lost is used as a supplementary
measure:
<list style="hanging">
<t>PL_NT = sum_NT(lost packets) / sum_NT(total
packets)</t>
</list></t>
</section>
</section>
<section title="Flow Grouping">
<section title="Flow Grouping Algorithm">
<t>The following grouping algorithm is RECOMMENDED for SBD
in this context and is sufficient and efficient for small to
moderate numbers of flows. For very large numbers of flows,
hundreds, a more complex clustering algorithm may be
substituted.</t>
<t>Flows determined to be experiencing congestion are
successively divided into groups based on freqest, PDV, and
skewest.</t>
<t>The first step is to determine which flows are
experiencing congestion. This is important, since if a flow
is not experiencing congestion its delay based metrics will
not describe the bottleneck, but the "noise" from the rest
of the path. Skewness, with proportion of packets loss as a
supplementary measure, is used to do this:
<list counter="grouping" style="format %d.">
<t>Grouping will be performed on flows where:
<list style="hanging">
<t>E_N(skewest) < 0 || PL_NT > p_l.</t>
</list></t>
</list></t>
<t>These flows, flows experiencing congestion, are then
progressively divided into groups based on the freqest, PDV,
and skewest summary statistics. The process proceeds
according to the following steps:
<list counter="grouping" style="format %d." >
<t>Group flows whose difference in sorted freqest is less than a
threshold:
<list style="hanging">
<t> diff(freqest) < p_f</t>
</list></t>
<t>Group flows whose difference in sorted E_N(PDV) is less than a
threshold:
<list style="hanging">
<t> diff(E_N(PDV)) < (p_pdv * E_N(PDV)) </t>
</list></t>
<t>Group flows whose difference in sorted E_N(skewest) or
PL_NT is less than a threshold:
<list style="hanging">
<t> if PL_NT < p_l
<list style="hanging">
<t>diff(E_N(skewness)) < p_s </t>
</list></t>
<t>otherwise
<list style="hanging">
<t>diff(PL_NT) < p_d </t>
</list></t>
</list></t>
</list></t>
<t>This procedure involves sorting the groups, according to
the measure being used to divide them. It is simple to
implement, and efficient for small numbers of flows, such as
are expected in RTCWEB.</t>
</section>
<section title="Using the flow group signal">
<t>A grouping decisions is made every T. Network
conditions can cause bottlenecks to fluctuate. A coupled
congestion controller MAY decide only to couple groups that
remain stable, say grouped together 90% of the time,
depending on its objectives. Recommendations concerning this are
beyond the scope of this draft and will be specific to the
coupled congestion controllers objectives.</t>
</section>
</section>
</section>
<section title="Measuring OWD">
<t>This section discusses the OWD measurements required for this
algorithm to detect shared bottlenecks.
</t>
<t>The SBD mechanism described in
this draft relies on differences between OWD measurements to avoid the
practical problems with measuring absolute OWD (see <xref
target="Hayes-LCN14"/> section IIIC). Since all summary statistics are
relative to the mean OWD and sender/receiver clock offsets
are approximately constant over the measurement periods, the
offset is subtracted out in the calculation.</t>
<section title="Time stamp resolution">
<t>The SBD mechanism requires timing information precise enough
to be able to make comparisons. As a rule of thumb, the time
resolution should be less than one hundredth of a typical paths range
of delays. In general, the lower the time resolution, the more
care that needs to be taken to ensure rounding errors don't bias the
skewness calculation.</t>
<t>Typical RTP media flows use sub-millisecond timers,
which should be adequate in most situations.</t>
</section>
<!--
<section title="System Timers">
<t>DavidH: possibly to be included as a guide in a subsequent
iteration, though probably not the TCP part.</t>
<t>
The following remarks discuss system timers, and may help in
some implementation scenarios where available timer
granularity could influence where in the system SBD is
performed.
</t>
<t>
For an implementation of SBD in kernel-space
the system's timestamp resolution is of importance: Earlier systems have the
accuracy of the timestamps given by the resolution of the clock mantained by
the kernel in jiffy, also called system's kernel tick, given by HZ or hz variables.
And the jiffy length is determined by the system's kernel tick. Newer Linux
systems have the kernel tick set by default to 250, sometimes also to 1000.
Newer FreeBSD systems have the kernel tick set 1000 by default.
Thus, yelding to jiffies of 4 or maximum of 1 ms. For the implementer of SBD
using the system's time resolution the size of one jiffy is relevant. Larger jiffy
values allow for better timer granularity and resolution, however, it comes at
the cost of more CPU cycles.
In newer systems, other timing source is the high-resolution kernel timer
introduced for sub-jiffy granularity. However, this is yet not supported in
all hardware architectures and, thus, it is recommended to the
implementer of SBD to first test its support and usability.
</t>
<t>
In particular for applications running on top of TCP, the implementer
of SBD could make use of the TCP-TS option, in similar way to LEDBAT, to get
OWD sample measurements. However, the TCP timestamp option does not
ensure higher resolution because it relies on the kernel jiffy length.
For an application sending enough traffic, the TCP-TS is updated at maximum
of 1 ms for a system's jiffy length of 1000. Also, the TCP-TS option is limited
to two four-byte fields, which also does not guarantee finer than millisecond
granularity.
Alternatively, reliable OWD samples can be also generate inside the
application itself and written into the packet's payload. The implementer of
SBD has to decide the necessary granurality given at this level by the amount
of data generated and the application's run-time performance.
</t>
<t>
In general, the implementer has to decide which granularity for SBD is necessary
depending on its application scenario. If the time granularity of SBD is limited to
a jiffy length and, thus, not higher than milliseconds, the OWD of the underlying
network path should also not be less than milliseconds. This would cause loss in
time precision and the SBD mechanism is unable to detect OWD oscillation, usually
represented by changes in the OWD's sample lowest bits.
</t>
</section>
-->
</section>
<!--
<section title="Networks and Parameter Settings">
<t>short discussion as to what parameters might be good, say for
data centers.</t>
</section>
-->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This work was part-funded by the European Community under its
Seventh Framework Programme through the Reducing Internet
Transport Latency (RITE) project (ICT-317700). The views
expressed are solely those of the authors. </t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
<!--
<t>All drafts are required to have an IANA considerations section (see
<xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
RFC 2434</xref> for a guide). If the draft does not require IANA to do
anything, the section contains an explicit statement that this is the
case (as above). If there are no requirements for IANA, the section will
be removed during conversion into an RFC by the RFC Editor.</t>
-->
</section>
<section anchor="Security" title="Security Considerations">
<t>The security considerations of <xref target="RFC3550">RFC
3550</xref>, <xref target="RFC4585">RFC 4585</xref>, and <xref
target="RFC5124">RFC 5124</xref> are
expected to apply.</t>
<t>Non-authenticated RTCP packets carrying shared bottleneck indications and summary
statistics could attackers to alter the bottleneck sharing
characteristics for private gain or disruption of other parties
communication.</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">
&RFC2119;
<!-- the following is the minimum to make xml2rfc happy -->
<!--
<reference anchor="min_ref">
<front>
<title>Minimal Reference</title>
<author initials="authInitials" surname="authSurName">
<organization></organization>
</author>
<date year="2006" />
</front>
</reference> -->
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC3550;
&RFC4585;
&RFC5124;
&RFC5481;
&RFC6817;
&I-D.welzl-rmcat-coupled-cc;
<!-- A reference written by by an organization not a person. -->
<reference anchor="Hayes-LCN14"
target="http://heim.ifi.uio.no/davihay/hayes14__pract_passiv_shared_bottl_detec-abstract.html">
<front>
<title>Practical Passive Shared Bottleneck Detection using Shape
Summary Statistics</title>
<author initials="D. A." surname="Hayes">
<organization>University of Oslo</organization>
</author>
<author initials="S." surname="Ferlin">
<organization>Simula Research Laboratory</organization>
</author>
<author initials="M." surname="Welzl">
<organization>University of Oslo</organization>
</author>
<date year="2014" month="September"/>
</front>
<seriesInfo name="Proc. the IEEE Local Computer Networks
(LCN)" value="p150-158"/>
</reference>
<reference anchor="ITU-Y1540"
target="http://www.itu.int/rec/T-REC-Y.1540-201103-I/en">
<front>
<title>Internet protocol data communication service - IP
packet transfer and availability performance
parameters</title>
<author>
<organization>ITU-T</organization>
</author>
<date year="2011" month="March"/>
</front>
<seriesInfo name="Series Y: Global Information
Infrastructure, Internet Protocol Aspects
and Next-Generation Networks" value=""/>
</reference>
</references>
<!-- <reference anchor="DOMINATION"
target="http://www.example.com/dominator.html"> <front>
<title>Ultimate Plan for Taking Over the World</title>
<author>
<organization>Mad Dominators, Inc.</organization>
</author>
<date year="1984" />
</front>
</reference> -->
<!-- <section anchor="app-additional" title="Additional Stuff">
<t>This becomes an Appendix.</t>
</section> -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:34 |