< draft-ietf-tcpm-generalized-ecn-03.txt   draft-ietf-tcpm-generalized-ecn-04.txt >
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Obsoletes: 5562 (if approved) B. Briscoe Obsoletes: 5562 (if approved) B. Briscoe
Intended status: Experimental CableLabs Intended status: Experimental CableLabs
Expires: April 25, 2019 October 22, 2018 Expires: January 9, 2020 July 8, 2019
ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control ECN++: Adding Explicit Congestion Notification (ECN) to TCP Control
Packets Packets
draft-ietf-tcpm-generalized-ecn-03 draft-ietf-tcpm-generalized-ecn-04
Abstract Abstract
This document describes an experimental modification to ECN when used This document describes an experimental modification to ECN when used
with TCP. It allows the use of ECN on the following TCP packets: with TCP. It allows the use of ECN on the following TCP packets:
SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions. SYNs, pure ACKs, Window probes, FINs, RSTs and retransmissions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 22, line 21 skipping to change at page 22, line 21
if the IP/ECN field on the SYN was ECT0, CE or either. Given most if the IP/ECN field on the SYN was ECT0, CE or either. Given most
web servers use Linux, this behaviour can most likely be traced to a web servers use Linux, this behaviour can most likely be traced to a
patch contributed in May 2012 that was first distributed in v3.5 of patch contributed in May 2012 that was first distributed in v3.5 of
the Linux kernel [strict-ecn]. The comment says "RFC3168 : 6.1.1 SYN the Linux kernel [strict-ecn]. The comment says "RFC3168 : 6.1.1 SYN
packets must not have ECT/ECN bits set. If we receive a SYN packet packets must not have ECT/ECN bits set. If we receive a SYN packet
with these bits set, it means a network is playing bad games with TOS with these bits set, it means a network is playing bad games with TOS
bits. In order to avoid possible false congestion notifications, we bits. In order to avoid possible false congestion notifications, we
disable TCP ECN negociation." Of course, some of the 84% might be disable TCP ECN negociation." Of course, some of the 84% might be
due to similar code in other OSs. due to similar code in other OSs.
For brevity we shall call this the "contra-Postel" ECN test, because For brevity we shall call this the "over-strict" ECN test, because it
it is conservative with what it accepts, contrary to Postel's is over-conservative with what it accepts, contrary to Postel's
robustness principle. A robust protocol will not usually assume robustness principle. A robust protocol will not usually assume
network mangling without comparing with the value originally sent, network mangling without comparing with the value originally sent,
and one packet is not sufficient to make an assumption with such and one packet is not sufficient to make an assumption with such
irreversible consequences anyway. irreversible consequences anyway.
Ironically, networks rarely seem to alter the IP/ECN field on a SYN Ironically, networks rarely seem to alter the IP/ECN field on a SYN
from zero to non-zero anyway. In a study conducted in Jan-May 2017 from zero to non-zero anyway. In a study conducted in Jan-May 2017
over millions of paths from vantage points in a few dozen mobile and over millions of paths from vantage points in a few dozen mobile and
fixed networks [Mandalari18], no such transition was observed. With fixed networks [Mandalari18], no such transition was observed. With
such a small or non-existent incidence of this sort of network such a small or non-existent incidence of this sort of network
mangling, it would be preferable to report any residual problem paths mangling, it would be preferable to report any residual problem paths
so that they can be fixed. so that they can be fixed.
Whatever, the widespread presence of this 'contra-Postel' test proves Whatever, the widespread presence of this 'over-strict' test proves
that RFC 5562 was correct to expect that ECT would be considered that RFC 5562 was correct to expect that ECT would be considered
invalid on SYNs. Nonetheless, it is not an insurmountable problem - invalid on SYNs. Nonetheless, it is not an insurmountable problem -
caching can work round it. The prevalence of these "contra-Postel" the over-strict test in Linux was patched in Apr 2019
[relax-strict-ecn] and caching can work round it where previous
versions of Linux are running. The prevalence of these "over-strict"
ECN servers makes it challenging to cache them all. However, ECN servers makes it challenging to cache them all. However,
Section 4.2.3 below explains how a cache of limited size can Section 4.2.3 below explains how a cache of limited size can
alleviate this problem for a client's most popular sites. alleviate this problem for a client's most popular sites.
For the future, [RFC8311] updates RFC 3168 to clarify that the IP/ECN For the future, [RFC8311] updates RFC 3168 to clarify that the IP/ECN
field does not have to be zero on a SYN if documented in an field does not have to be zero on a SYN if documented in an
experimental RFC such as the present ECN++ specification. experimental RFC such as the present ECN++ specification.
4.2.3. Caching Strategies for ECT on SYNs 4.2.3. Caching Strategies for ECT on SYNs
skipping to change at page 23, line 18 skipping to change at page 23, line 18
above, an initiator might combine AccECN with three candidate caching above, an initiator might combine AccECN with three candidate caching
strategies for setting ECT on a SYN: strategies for setting ECT on a SYN:
(S1): Pessimistic ECT and cache successes: The initiator always (S1): Pessimistic ECT and cache successes: The initiator always
requests AccECN, but by default without ECT on the SYN. Then requests AccECN, but by default without ECT on the SYN. Then
it caches those servers that confirm that they support AccECN it caches those servers that confirm that they support AccECN
as 'ECT SYN OK'. On a subsequent connection to any server as 'ECT SYN OK'. On a subsequent connection to any server
that supports AccECN, the initiator can then set ECT on the that supports AccECN, the initiator can then set ECT on the
SYN. When connecting to other servers (non-ECN or classic SYN. When connecting to other servers (non-ECN or classic
ECN) it will not set ECT on the SYN, so it will not fail the ECN) it will not set ECT on the SYN, so it will not fail the
'contra-Postel' test. 'over-strict' ECN test.
Longer term, as servers upgrade to AccECN, the initiator is Longer term, as servers upgrade to AccECN, the initiator is
still requesting AccECN, so it will add them to the cache and still requesting AccECN, so it will add them to the cache and
use ECT on subsequent SYNs to those servers. However, use ECT on subsequent SYNs to those servers. However,
assuming it has to cap the size of the cache, the client will assuming it has to cap the size of the cache, the client will
not have the benefit of ECT SYNs to those less frequently used not have the benefit of ECT SYNs to those less frequently used
AccECN servers expelled from its cache. AccECN servers expelled from its cache.
(S2): Optimistic ECT: The initiator always requests AccECN and by (S2): Optimistic ECT: The initiator always requests AccECN and by
default sets ECT on the SYN. Then, if the server response default sets ECT on the SYN. Then, if the server response
shows it has no AccECN logic (so it cannot feed back a CE shows it has no AccECN logic (so it cannot feed back a CE
mark), the initiator conservatively behaves as if the SYN was mark), the initiator conservatively behaves as if the SYN was
CE-marked, by reducing its initial window. CE-marked, by reducing its initial window.
A. No cache. A. No cache.
B. Cache failures: The optimistic ECT strategy can be B. Cache failures: The optimistic ECT strategy can be
improved by caching solely those servers that do not improved by caching solely those servers that do not
support AccECN as 'ECT SYN NOK'. This would include non- support AccECN as 'ECT SYN NOK'. This would include non-
ECN servers and all Classic ECN servers whether 'contra- ECN servers and all Classic ECN servers whether 'over-
Postel' or not. On subsequent connections to these non- strict' or not. On subsequent connections to these non-
AccECN servers, the initiator will still request AccECN AccECN servers, the initiator will still request AccECN
but not set ECT on the SYN. Then, the connection can but not set ECT on the SYN. Then, the connection can
still fall back to Classic ECN, if the server supports it, still fall back to Classic ECN, if the server supports it,
and the initiator can use its full initial window (if it and the initiator can use its full initial window (if it
has enough request data to need it). has enough request data to need it).
Longer term, as servers upgrade to AccECN, the initiator Longer term, as servers upgrade to AccECN, the initiator
will remove them from the cache and use ECT on subsequent will remove them from the cache and use ECT on subsequent
SYNs to that server. SYNs to that server.
skipping to change at page 24, line 28 skipping to change at page 24, line 28
that each tenant mostly communicates with its own VMs. that each tenant mostly communicates with its own VMs.
For unmanaged environments like the public Internet, pragmatically For unmanaged environments like the public Internet, pragmatically
the choice is between strategies (S1), (S2A) and (S2B). The the choice is between strategies (S1), (S2A) and (S2B). The
normative specification for ECT on a SYN in Section 3.2.1 recommends normative specification for ECT on a SYN in Section 3.2.1 recommends
the "optimistic ECT and cache failures" strategy (S2B) but the choice the "optimistic ECT and cache failures" strategy (S2B) but the choice
depends on the implementer's motivation for using ECN++, and the depends on the implementer's motivation for using ECN++, and the
deployment prevalence of different technologies and bug-fixes. For deployment prevalence of different technologies and bug-fixes. For
instance, if a user's Internet access bottleneck supported L4S ECN instance, if a user's Internet access bottleneck supported L4S ECN
but not Classic ECN, strategy (S2A) would make most sense and there but not Classic ECN, strategy (S2A) would make most sense and there
would be no point trying to avoid the 'contra-Postel' test and would be no point trying to avoid the 'over-strict' test and
negotiate Classic ECN. negotiate Classic ECN.
o The "pessimistic ECT and cache successes" strategy (S1) suffers o The "pessimistic ECT and cache successes" strategy (S1) suffers
from exposing the initial SYN to the prevailing loss level, even from exposing the initial SYN to the prevailing loss level, even
if the server supports ECT on SYNs, but only on the first if the server supports ECT on SYNs, but only on the first
connection to each AccECN server. If AccECN becomes widely connection to each AccECN server. If AccECN becomes widely
deployed on servers, SYNs to those AccECN servers that are less deployed on servers, SYNs to those AccECN servers that are less
frequently used by the client and therefore don't fit in the cache frequently used by the client and therefore don't fit in the cache
will not benefit from ECN protection at all. will not benefit from ECN protection at all.
o The "optimistic ECT without a cache" strategy (S2A) is the o The "optimistic ECT without a cache" strategy (S2A) is the
simplest. It would satisfy the goal of an implementer who is simplest. It would satisfy the goal of an implementer who is
solely interested in ultra-low latency using AccECN and ECN++ solely interested in ultra-low latency using AccECN and ECN++
(e.g. accessing L4S servers) and is not concerned about fall-back (e.g. accessing L4S servers) and is not concerned about fall-back
to Classic ECN (e.g. when accessing other servers). to Classic ECN (e.g. when accessing other servers).
o The "optimistic ECT and cache failures" strategy (S2B) exploits o The "optimistic ECT and cache failures" strategy (S2B) exploits
ECT on SYNs from the very first attempt. But if the server turns ECT on SYNs from the very first attempt. But if the server turns
out to be 'contra-Postel' it will disable ECN for the connection, out to be 'over-strict' it will disable ECN for the connection,
but only for the first connection if it's one of the client's more but only for the first connection if it's one of the client's more
popular servers that fits in the cache. If the server turns out popular servers that fits in the cache. If the server turns out
not to support AccECN, the initiator has to conservatively limit not to support AccECN, the initiator has to conservatively limit
its initial window, but again only for the first connection if its initial window, but again only for the first connection if
it's one of the client's more popular servers (and anyway this it's one of the client's more popular servers (and anyway this
rarely makes any difference when most client requests fit in a rarely makes any difference when most client requests fit in a
single packet). single packet).
Note that, if AccECN deployment grows, caching successes (S1) starts Note that, if AccECN deployment grows, caching successes (S1) starts
off small then grows, while caching failures (S2B) becomes large at off small then grows, while caching failures (S2B) becomes large at
skipping to change at page 31, line 28 skipping to change at page 31, line 28
not; it just needs to respond to congestion feedback as a whole by not; it just needs to respond to congestion feedback as a whole by
reducing its congestion window (cwnd), which limits the data it can reducing its congestion window (cwnd), which limits the data it can
launch into flight through the congested bottleneck. If it is purely launch into flight through the congested bottleneck. If it is purely
receiving data and sending only Pure ACKs, reducing cwnd will have receiving data and sending only Pure ACKs, reducing cwnd will have
caused it no harm, having no effect on its ACK rate (the next caused it no harm, having no effect on its ACK rate (the next
subsection addresses that). subsection addresses that).
However, when a host is sending data as well as Pure ACKs, it would However, when a host is sending data as well as Pure ACKs, it would
not be right for CE-marks on Pure ACKs and on data packets to induce not be right for CE-marks on Pure ACKs and on data packets to induce
the same reduction in cwnd. A possible way to address this issue the same reduction in cwnd. A possible way to address this issue
would be to weight the response by the size of the marked packets. would be to weight the response by the size of the marked packets
For instance, one could calculate the fraction of CE-marked bytes (assuming the congestion control supports a weighted response, e.g.
(headers and data) over each round trip (say) as follows: [RFC8257]). For instance, one could calculate the fraction of CE-
marked bytes (headers and data) over each round trip (say) as
follows:
(CE-marked header bytes + CE-marked data bytes) / (all header (CE-marked header bytes + CE-marked data bytes) / (all header
bytes + all data bytes) bytes + all data bytes)
Header bytes can be calculated by multiplying a packet count by a Header bytes can be calculated by multiplying a packet count by a
nominal header size, which is possible with AccECN feedback, because nominal header size, which is possible with AccECN feedback, because
it gives a count of CE-marked packets (as well as CE-marked bytes). it gives a count of CE-marked packets (as well as CE-marked bytes).
The above simple aggregate calculation caters for the full range of The above simple aggregate calculation caters for the full range of
scenarios; from all Pure ACKs to just a few interspersed with data scenarios; from all Pure ACKs to just a few interspersed with data
packets. packets.
skipping to change at page 40, line 16 skipping to change at page 40, line 18
of Norway through the TimeIn project. The views expressed here are of Norway through the TimeIn project. The views expressed here are
solely those of the authors. solely those of the authors.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-tcpm-accurate-ecn] [I-D.ietf-tcpm-accurate-ecn]
Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More Briscoe, B., Kuehlewind, M., and R. Scheffenegger, "More
Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate- Accurate ECN Feedback in TCP", draft-ietf-tcpm-accurate-
ecn-07 (work in progress), July 2018. ecn-08 (work in progress), March 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001, RFC 3168, DOI 10.17487/RFC3168, September 2001,
<https://www.rfc-editor.org/info/rfc3168>. <https://www.rfc-editor.org/info/rfc3168>.
skipping to change at page 41, line 12 skipping to change at page 41, line 19
(PAM'15) pp193-205, 2015, <https://link.springer.com/ (PAM'15) pp193-205, 2015, <https://link.springer.com/
chapter/10.1007/978-3-319-15509-8_15>. chapter/10.1007/978-3-319-15509-8_15>.
[ECN-PLUS] [ECN-PLUS]
Kuzmanovic, A., "The Power of Explicit Congestion Kuzmanovic, A., "The Power of Explicit Congestion
Notification", ACM SIGCOMM 35(4):61--72, 2005, Notification", ACM SIGCOMM 35(4):61--72, 2005,
<http://dl.acm.org/citation.cfm?id=1080100>. <http://dl.acm.org/citation.cfm?id=1080100>.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-15 (work and Secure Transport", draft-ietf-quic-transport-20 (work
in progress), October 2018. in progress), April 2019.
[I-D.ietf-tsvwg-ecn-l4s-id] [I-D.ietf-tsvwg-ecn-l4s-id]
Schepper, K. and B. Briscoe, "Identifying Modified Schepper, K. and B. Briscoe, "Identifying Modified
Explicit Congestion Notification (ECN) Semantics for Explicit Congestion Notification (ECN) Semantics for
Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s- Ultra-Low Queuing Delay (L4S)", draft-ietf-tsvwg-ecn-l4s-
id-03 (work in progress), July 2018. id-06 (work in progress), March 2019.
[I-D.ietf-tsvwg-l4s-arch] [I-D.ietf-tsvwg-l4s-arch]
Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency, Briscoe, B., Schepper, K., and M. Bagnulo, "Low Latency,
Low Loss, Scalable Throughput (L4S) Internet Service: Low Loss, Scalable Throughput (L4S) Internet Service:
Architecture", draft-ietf-tsvwg-l4s-arch-02 (work in Architecture", draft-ietf-tsvwg-l4s-arch-03 (work in
progress), March 2018. progress), October 2018.
[I-D.stewart-tsvwg-sctpecn] [I-D.stewart-tsvwg-sctpecn]
Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream Stewart, R., Tuexen, M., and X. Dong, "ECN for Stream
Control Transmission Protocol (SCTP)", draft-stewart- Control Transmission Protocol (SCTP)", draft-stewart-
tsvwg-sctpecn-05 (work in progress), January 2014. tsvwg-sctpecn-05 (work in progress), January 2014.
[judd-nsdi] [judd-nsdi]
Judd, G., "Attaining the promise and avoiding the pitfalls Judd, G., "Attaining the promise and avoiding the pitfalls
of TCP in the Datacenter", USENIX Symposium on Networked of TCP in the Datacenter", USENIX Symposium on Networked
Systems Design and Implementation (NSDI'15) pp.145-157, Systems Design and Implementation (NSDI'15) pp.145-157,
skipping to change at page 42, line 12 skipping to change at page 42, line 18
over Mobile", IEEE Communications Magazine , March 2018, over Mobile", IEEE Communications Magazine , March 2018,
<https://ieeexplore.ieee.org/document/8316790>. <https://ieeexplore.ieee.org/document/8316790>.
[Manzoor17] [Manzoor17]
Manzoor, J., Drago, I., and R. Sadre, "How HTTP/2 is Manzoor, J., Drago, I., and R. Sadre, "How HTTP/2 is
changing Web traffic and how to detect it", In Proc: changing Web traffic and how to detect it", In Proc:
Network Traffic Measurement and Analysis Conference (TMA) Network Traffic Measurement and Analysis Conference (TMA)
2017 pp.1-9, June 2017, 2017 pp.1-9, June 2017,
<https://ieeexplore.ieee.org/document/8002899>. <https://ieeexplore.ieee.org/document/8002899>.
[relax-strict-ecn]
Tilmans, O., "tcp: Accept ECT on SYN in the presence of
RFC8311", Linux netdev patch list , April 2019,
<https://lore.kernel.org/patchwork/patch/1057812/>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
skipping to change at page 43, line 32 skipping to change at page 43, line 46
<https://www.rfc-editor.org/info/rfc7661>. <https://www.rfc-editor.org/info/rfc7661>.
[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., [RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L.,
and G. Judd, "Data Center TCP (DCTCP): TCP Congestion and G. Judd, "Data Center TCP (DCTCP): TCP Congestion
Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257, Control for Data Centers", RFC 8257, DOI 10.17487/RFC8257,
October 2017, <https://www.rfc-editor.org/info/rfc8257>. October 2017, <https://www.rfc-editor.org/info/rfc8257>.
[strict-ecn] [strict-ecn]
Dumazet, E., "tcp: be more strict before accepting ECN Dumazet, E., "tcp: be more strict before accepting ECN
negociation", Linux netdev patch list , May 2012, negociation", Linux netdev patch list , May 2012,
<https://github.com/torvalds/linux/commit/ <https://patchwork.ozlabs.org/patch/156953/>.
bd14b1b2e29bd6812597f896dde06eaf7c6d2f24#diff-
5c7c60ed5f9efb6bce97ff5233f17282>.
Authors' Addresses Authors' Addresses
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6249500 Phone: 34 91 6249500
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
Bob Briscoe Bob Briscoe
CableLabs CableLabs
UK UK
Email: ietf@bobbriscoe.net Email: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
 End of changes. 20 change blocks. 
26 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/