< draft-ietf-tcpm-accurate-ecn-08.txt   draft-ietf-tcpm-accurate-ecn-09.txt >
TCP Maintenance & Minor Extensions (tcpm) B. Briscoe TCP Maintenance & Minor Extensions (tcpm) B. Briscoe
Internet-Draft CableLabs Internet-Draft CableLabs
Intended status: Experimental M. Kuehlewind Intended status: Experimental M. Kuehlewind
Expires: September 12, 2019 ETH Zurich Expires: January 9, 2020 Ericsson
R. Scheffenegger R. Scheffenegger
March 11, 2019 NetApp
July 8, 2019
More Accurate ECN Feedback in TCP More Accurate ECN Feedback in TCP
draft-ietf-tcpm-accurate-ecn-08 draft-ietf-tcpm-accurate-ecn-09
Abstract Abstract
Explicit Congestion Notification (ECN) is a mechanism where network Explicit Congestion Notification (ECN) is a mechanism where network
nodes can mark IP packets instead of dropping them to indicate nodes can mark IP packets instead of dropping them to indicate
incipient congestion to the end-points. Receivers with an ECN- incipient congestion to the end-points. Receivers with an ECN-
capable transport protocol feed back this information to the sender. capable transport protocol feed back this information to the sender.
ECN is specified for TCP in such a way that only one feedback signal ECN is specified for TCP in such a way that only one feedback signal
can be transmitted per Round-Trip Time (RTT). Recent new TCP can be transmitted per Round-Trip Time (RTT). Recent new TCP
mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP) mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP)
skipping to change at page 1, line 47 skipping to change at page 1, line 48
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 September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
3.2.8. Usage of the AccECN TCP Option . . . . . . . . . . . 25 3.2.8. Usage of the AccECN TCP Option . . . . . . . . . . . 25
3.3. Requirements for TCP Proxies, Offload Engines and other 3.3. Requirements for TCP Proxies, Offload Engines and other
Middleboxes on AccECN Compliance . . . . . . . . . . . . 27 Middleboxes on AccECN Compliance . . . . . . . . . . . . 27
4. Interaction with Other TCP Variants . . . . . . . . . . . . . 28 4. Interaction with Other TCP Variants . . . . . . . . . . . . . 28
4.1. Compatibility with SYN Cookies . . . . . . . . . . . . . 28 4.1. Compatibility with SYN Cookies . . . . . . . . . . . . . 28
4.2. Compatibility with Other TCP Options and Experiments . . 29 4.2. Compatibility with Other TCP Options and Experiments . . 29
4.3. Compatibility with Feedback Integrity Mechanisms . . . . 29 4.3. Compatibility with Feedback Integrity Mechanisms . . . . 29
5. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 30 5. Protocol Properties . . . . . . . . . . . . . . . . . . . . . 30
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 34 9. Comments Solicited . . . . . . . . . . . . . . . . . . . . . 34
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
10.2. Informative References . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Example Algorithms . . . . . . . . . . . . . . . . . 37 Appendix A. Example Algorithms . . . . . . . . . . . . . . . . . 37
A.1. Example Algorithm to Encode/Decode the AccECN Option . . 37 A.1. Example Algorithm to Encode/Decode the AccECN Option . . 37
A.2. Example Algorithm for Safety Against Long Sequences of A.2. Example Algorithm for Safety Against Long Sequences of
ACK Loss . . . . . . . . . . . . . . . . . . . . . . . . 38 ACK Loss . . . . . . . . . . . . . . . . . . . . . . . . 38
A.2.1. Safety Algorithm without the AccECN Option . . . . . 38 A.2.1. Safety Algorithm without the AccECN Option . . . . . 38
A.2.2. Safety Algorithm with the AccECN Option . . . . . . . 40 A.2.2. Safety Algorithm with the AccECN Option . . . . . . . 40
skipping to change at page 11, line 13 skipping to change at page 11, line 13
frequently, but this is left up to the implementer. frequently, but this is left up to the implementer.
2.4. Feedback Metrics 2.4. Feedback Metrics
The CE packet counter in the ACE field and the CE byte counter in the The CE packet counter in the ACE field and the CE byte counter in the
AccECN Option both provide feedback on received CE-marks. The CE AccECN Option both provide feedback on received CE-marks. The CE
packet counter includes control packets that do not have payload packet counter includes control packets that do not have payload
data, while the CE byte counter solely includes marked payload bytes. data, while the CE byte counter solely includes marked payload bytes.
If both are present, the byte counter in the option will provide the If both are present, the byte counter in the option will provide the
more accurate information needed for modern congestion control and more accurate information needed for modern congestion control and
policing schemes, such as DCTCP or ConEx. If the option is stripped, policing schemes, such as L4S, DCTCP or ConEx. If the option is
a simple algorithm to estimate the number of marked bytes from the stripped, a simple algorithm to estimate the number of marked bytes
ACE field is given in Appendix A.3. from the ACE field is given in Appendix A.3.
Feedback in bytes is recommended in order to protect against the Feedback in bytes is recommended in order to protect against the
receiver using attacks similar to 'ACK-Division' to artificially receiver using attacks similar to 'ACK-Division' to artificially
inflate the congestion window, which is why [RFC5681] now recommends inflate the congestion window, which is why [RFC5681] now recommends
that TCP counts acknowledged bytes not packets. that TCP counts acknowledged bytes not packets.
2.5. Generic (Dumb) Reflector 2.5. Generic (Dumb) Reflector
The ACE field provides information about CE markings on both data and The ACE field provides information about CE markings on both data and
control packets. According to [RFC3168] the Data Sender is meant to control packets. According to [RFC3168] the Data Sender is meant to
skipping to change at page 17, line 27 skipping to change at page 17, line 27
SYN/ACKs after AccECN support has been successfully negotiated during SYN/ACKs after AccECN support has been successfully negotiated during
a simultaneous open). a simultaneous open).
With only one exception, on any packet with the SYN flag cleared With only one exception, on any packet with the SYN flag cleared
(SYN=0), the Data Receiver MUST encode the three least significant (SYN=0), the Data Receiver MUST encode the three least significant
bits of its r.cep counter into the ACE field it feeds back to the bits of its r.cep counter into the ACE field it feeds back to the
Data Sender. Data Sender.
There is only one exception to this rule: On the final ACK of the There is only one exception to this rule: On the final ACK of the
3-way handshake (3WHS), a TCP client (A) in AccECN mode MUST use the 3-way handshake (3WHS), a TCP client (A) in AccECN mode MUST use the
ACE field to feed back which of the 4 possible values of the IP-ECN appropriate values of the ACE field in Table 3 to feed back which of
field were on the SYN/ACK (the binary encoding is the same as that the 4 possible values of the IP-ECN field were on the SYN/ACK (the
used on the SYN/ACK). Table 3 shows the meaning of each possible binary encoding is the same as that used on the SYN/ACK). Table 3
value of the ACE field on the ACK of the SYN/ACK and the value that shows the meaning of each possible value of the ACE field on the ACK
an AccECN server MUST set s.cep to as a result. The encoding in of the SYN/ACK and the value that an AccECN server MUST set s.cep to
Table 3 is solely applicable on a packet in the client-server as a result. The encoding in Table 3 is solely applicable on a
direction with an acknowledgement number 1 greater than the Initial packet in the client-server direction with an acknowledgement number
Sequence Number (ISN) that was used by the server. 1 greater than the Initial Sequence Number (ISN) that was used by the
server.
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
| ACE on ACK | IP-ECN codepoint on | Initial s.cep of | | ACE on ACK | IP-ECN codepoint on | Initial s.cep of |
| of SYN/ACK | SYN/ACK inferred by | server in AccECN mode | | of SYN/ACK | SYN/ACK inferred by | server in AccECN mode |
| | server | | | | server | |
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
| 0b000 | {Notes 1, 2} | Disable ECN | | 0b000 | {Notes 1, 3} | Disable ECN |
| 0b001 | {Notes 2, 3} | 5 | | 0b001 | {Notes 2, 3} | 5 |
| 0b010 | Not-ECT | 5 | | 0b010 | Not-ECT | 5 |
| 0b011 | ECT(1) | 5 | | 0b011 | ECT(1) | 5 |
| 0b100 | ECT(0) | 5 | | 0b100 | ECT(0) | 5 |
| 0b101 | Currently Unused {Note 3} | 5 | | 0b101 | Currently Unused {Note 2} | 5 |
| 0b110 | CE | 6 | | 0b110 | CE | 6 |
| 0b111 | Currently Unused {Note 3} | 5 | | 0b111 | Currently Unused {Note 2} | 5 |
+--------------+---------------------------+------------------------+ +--------------+---------------------------+------------------------+
Table 3: Meaning of the ACE field on the ACK of the SYN/ACK Table 3: Meaning of the ACE field on the ACK of the SYN/ACK
{Note 1}: If the server is in AccECN mode, the value of zero raises {Note 1}: If the server is in AccECN mode, the value of zero raises
suspicion of zeroing of the ACE field on the path (see suspicion of zeroing of the ACE field on the path (see
Section 3.2.3). Section 3.2.3).
{Note 2}: If a server is in AccECN mode, there ought to be no valid {Note 2}: If the server is in AccECN mode, these values are Currently
case where the ACE field on the last ACK of the 3WHS has a value of Unused but the AccECN server's behaviour is still defined for forward
0b000 or 0b001. compatibility. Then the designer of a future protocol can know for
certain what AccECN servers will do with these codepoints.
However, in the case where a server that implements AccECN is also {Note 3}: In the case where a server that implements AccECN is also
using a stateless handshake (termed a SYN cookie) it will not using a stateless handshake (termed a SYN cookie) it will not
remember whether it entered AccECN mode. Then these two values remember whether it entered AccECN mode. The values 0b000 or 0b001
remind it that it did not enter AccECN mode (see Section 4.1 for will remind it that it did not enter AccECN mode, because AccECN does
details). not use them (see Section 4.1 for details).
{Note 3}: If the server is in AccECN mode, these values are Currently If a stateless server that implements AccECN receives either of these
Unused but the AccECN server's behaviour is still defined for forward two values in the ACK, its action is implementation-dependent and
compatibility. outside the scope of this spec, It will certainly not take the action
in the third column because, after it receives either of these
values, it is not in AccECN mode. I.e., it will not disable ECN (at
least not just because ACE is 0b000) and it will not set s.cep.
3.2.3. Testing for Zeroing of the ACE Field 3.2.3. Testing for Zeroing of the ACE Field
Section 3.2.2 required the Data Receiver to initialize the r.cep Section 3.2.2 required the Data Receiver to initialize the r.cep
counter to a non-zero value. Therefore, in either direction the counter to a non-zero value. Therefore, in either direction the
initial value of the ACE field ought to be non-zero. initial value of the ACE field ought to be non-zero.
If AccECN has been successfully negotiated, the Data Sender SHOULD If AccECN has been successfully negotiated, the Data Sender SHOULD
check the initial value of the ACE field in the first arriving check the initial value of the ACE field in the first arriving
segment with SYN=0. If the initial value of the ACE field is zero segment with SYN=0. If the initial value of the ACE field is zero
skipping to change at page 23, line 28 skipping to change at page 23, line 33
another packet with the AccECN Option at a later point during the another packet with the AccECN Option at a later point during the
connection but should monitor if that packet got lost as well, in connection but should monitor if that packet got lost as well, in
which case it SHOULD disable the sending of the AccECN Option for which case it SHOULD disable the sending of the AccECN Option for
this half-connection. this half-connection.
Similarly, an AccECN end-point MAY separately memorize which data Similarly, an AccECN end-point MAY separately memorize which data
packets carried an AccECN Option and disable the sending of AccECN packets carried an AccECN Option and disable the sending of AccECN
Options if the loss probability of those packets is significantly Options if the loss probability of those packets is significantly
higher than that of all other data packets in the same connection. higher than that of all other data packets in the same connection.
3.2.7.3. Testing for Stripping of the AccECN Option 3.2.7.3. Testing for Absence of the AccECN Option
If the TCP client has successfully negotiated AccECN but does not If the TCP client has successfully negotiated AccECN but does not
receive an AccECN Option on the SYN/ACK, it switches into a mode that receive an AccECN Option on the SYN/ACK (e.g. because is has been
assumes that the AccECN Option is not available for this half stripped by a middlebox or not sent by the server), the client
connection. switches into a mode that assumes that the AccECN Option is not
available for this half connection.
Similarly, if the TCP server has successfully negotiated AccECN but Similarly, if the TCP server has successfully negotiated AccECN but
does not receive an AccECN Option on the first segment that does not receive an AccECN Option on the first segment that
acknowledges sequence space at least covering the ISN, it switches acknowledges sequence space at least covering the ISN, it switches
into a mode that assumes that the AccECN Option is not available for into a mode that assumes that the AccECN Option is not available for
this half connection. this half connection.
While a host is in this mode that assumes incoming AccECN Options are While a host is in this mode that assumes incoming AccECN Options are
not available, it MUST adopt the conservative interpretation of the not available, it MUST adopt the conservative interpretation of the
ACE field discussed in Section 3.2.5. However, it cannot make any ACE field discussed in Section 3.2.5. However, it cannot make any
skipping to change at page 33, line 48 skipping to change at page 34, line 8
this downgrade attack, but it is mentioned here in case someone else this downgrade attack, but it is mentioned here in case someone else
can contrive one. can contrive one.
The AccECN protocol is not believed to introduce any new privacy The AccECN protocol is not believed to introduce any new privacy
concerns, because it merely counts and feeds back signals at the concerns, because it merely counts and feeds back signals at the
transport layer that had already been visible at the IP layer. transport layer that had already been visible at the IP layer.
8. Acknowledgements 8. Acknowledgements
We want to thank Koen De Schepper, Praveen Balasubramanian, Michael We want to thank Koen De Schepper, Praveen Balasubramanian, Michael
Welzl, Gorry Fairhurst, David Black, Spencer Dawkins, Michael Scharf Welzl, Gorry Fairhurst, David Black, Spencer Dawkins, Michael Scharf,
and Michael Tuexen for their input and discussion. The idea of using Michael Tuexen and Yuchung Cheng for their input and discussion. The
the three ECN-related TCP flags as one field for more accurate TCP- idea of using the three ECN-related TCP flags as one field for more
ECN feedback was first introduced in the re-ECN protocol that was the accurate TCP-ECN feedback was first introduced in the re-ECN protocol
ancestor of ConEx. that was the ancestor of ConEx.
Bob Briscoe was part-funded by the European Community under its Bob Briscoe was part-funded by the European Community under its
Seventh Framework Programme through the Reducing Internet Transport Seventh Framework Programme through the Reducing Internet Transport
Latency (RITE) project (ICT-317700) and through the Trilogy 2 project Latency (RITE) project (ICT-317700) and through the Trilogy 2 project
(ICT-317756). He was also part-funded by the Research Council of (ICT-317756). He was also part-funded by the Research Council of
Norway through the TimeIn project. The views expressed here are Norway through the TimeIn project. The views expressed here are
solely those of the authors. solely those of the authors.
Mirja Kuehlewind was partly supported by the European Commission Mirja Kuehlewind was partly supported by the European Commission
under Horizon 2020 grant agreement no. 688421 Measurement and under Horizon 2020 grant agreement no. 688421 Measurement and
skipping to change at page 35, line 29 skipping to change at page 35, line 37
[I-D.kuehlewind-tcpm-ecn-fallback] [I-D.kuehlewind-tcpm-ecn-fallback]
Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path Kuehlewind, M. and B. Trammell, "A Mechanism for ECN Path
Probing and Fallback", draft-kuehlewind-tcpm-ecn- Probing and Fallback", draft-kuehlewind-tcpm-ecn-
fallback-01 (work in progress), September 2013. fallback-01 (work in progress), September 2013.
[Mandalari18] [Mandalari18]
Mandalari, A., Lutu, A., Briscoe, B., Bagnulo, M., and Oe. Mandalari, A., Lutu, A., Briscoe, B., Bagnulo, M., and Oe.
Alay, "Measuring ECN++: Good News for ++, Bad News for ECN Alay, "Measuring ECN++: Good News for ++, Bad News for ECN
over Mobile", IEEE Communications Magazine , March 2018. over Mobile", IEEE Communications Magazine , March 2018.
(to appear)
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, DOI 10.17487/RFC3540, June 2003, RFC 3540, DOI 10.17487/RFC3540, June 2003,
<https://www.rfc-editor.org/info/rfc3540>. <https://www.rfc-editor.org/info/rfc3540>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K.
skipping to change at page 37, line 41 skipping to change at page 37, line 41
ECEB = r.ceb % DIVOPT ECEB = r.ceb % DIVOPT
where '%' is the modulo operator. where '%' is the modulo operator.
On the arrival of an AccECN Option, the Data Sender uses the TCP On the arrival of an AccECN Option, the Data Sender uses the TCP
acknowledgement number and any SACK options to calculate newlyAckedB, acknowledgement number and any SACK options to calculate newlyAckedB,
the amount of new data that the ACK acknowledges in bytes. If the amount of new data that the ACK acknowledges in bytes. If
newlyAckedB is negative it means that a more up to date ACK has newlyAckedB is negative it means that a more up to date ACK has
already been processed, so this ACK has been superseded and the Data already been processed, so this ACK has been superseded and the Data
Sender has to ignore the AccECN Option. Then the Data Sender Sender has to ignore the AccECN Option. Otherwise, the Data Sender
calculates the minimum difference d.ceb between the ECEB field and calculates the minimum difference d.ceb between the ECEB field and
its local s.ceb counter, using modulo arithmetic as follows: its local s.ceb counter, using modulo arithmetic as follows:
if (newlyAckedB >= 0) { if (newlyAckedB >= 0) {
d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT d.ceb = (ECEB + DIVOPT - (s.ceb % DIVOPT)) % DIVOPT
s.ceb += d.ceb s.ceb += d.ceb
} }
For example, if s.ceb is 33,554,433 and ECEB is 1461 (both decimal), For example, if s.ceb is 33,554,433 and ECEB is 1461 (both decimal),
then then
skipping to change at page 45, line 35 skipping to change at page 45, line 35
arrive with the pattern tagged as 'Broken'. The 'Nonce' pattern arrive with the pattern tagged as 'Broken'. The 'Nonce' pattern
could be a sign that a few servers have implemented the ECN Nonce could be a sign that a few servers have implemented the ECN Nonce
[RFC3540], which has now been reclassified as historic [RFC8311], [RFC3540], which has now been reclassified as historic [RFC8311],
or it could be the random result of some unknown middlebox or it could be the random result of some unknown middlebox
behaviour. The greater prevalence of the 'Broken' pattern behaviour. The greater prevalence of the 'Broken' pattern
suggests that some instances still exist of the broken code that suggests that some instances still exist of the broken code that
reflects the reserved flags on the SYN. reflects the reserved flags on the SYN.
The requirement not to reject unexpected initial values of the ACE The requirement not to reject unexpected initial values of the ACE
counter (in the main TCP header) in the last para of Section 3.2.3 counter (in the main TCP header) in the last para of Section 3.2.3
ensures that 5 unused codepoints on the final ACK of the 3WHS and ensures that 3 unused codepoints on the final ACK of the 3WHS and
7 unused values on the first data packet from the server could be 7 unused values on the first data packet from the server could be
used to declare future variants of the AccECN protocol. The word used to declare future variants of the AccECN protocol. The word
'declare' is used rather than 'negotiate' because, at this late 'declare' is used rather than 'negotiate' because, at this late
stage in the 3WHS, it would be too late for a negotiation between stage in the 3WHS, it would be too late for a negotiation between
the endpoints to be completed. A similar requirement not to the endpoints to be completed. A similar requirement not to
reject unexpected initial values in the TCP option reject unexpected initial values in the TCP option
(Section 3.2.7.4) is for the same purpose. If traversal of the (Section 3.2.7.4) is for the same purpose. If traversal of the
TCP option were reliable, this would have enabled a far wider TCP option were reliable, this would have enabled a far wider
range of future variation of the whole AccECN protocol. range of future variation of the whole AccECN protocol.
Nonetheless, it could be used to reliably negotiate a wide range Nonetheless, it could be used to reliably negotiate a wide range
skipping to change at page 46, line 31 skipping to change at page 46, line 31
Authors' Addresses Authors' Addresses
Bob Briscoe Bob Briscoe
CableLabs CableLabs
UK UK
EMail: ietf@bobbriscoe.net EMail: ietf@bobbriscoe.net
URI: http://bobbriscoe.net/ URI: http://bobbriscoe.net/
Mirja Kuehlewind Mirja Kuehlewind
ETH Zurich Ericsson
Zurich Germany
Switzerland
EMail: mirja.kuehlewind@tik.ee.ethz.ch EMail: ietf@kuehlewind.net
Richard Scheffenegger Richard Scheffenegger
NetApp
Vienna Vienna
Austria Austria
EMail: rscheff@gmx.at EMail: Richard.Scheffenegger@netapp.com
 End of changes. 24 change blocks. 
46 lines changed or deleted 51 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/