draft-ietf-tsvwg-byte-pkt-congest-06.txt   draft-ietf-tsvwg-byte-pkt-congest-07.txt 
Transport Area Working Group B. Briscoe Transport Area Working Group B. Briscoe
Internet-Draft BT Internet-Draft BT
Updates: 2309 (if approved) J. Manner Updates: 2309 (if approved) J. Manner
Intended status: BCP Aalto University Intended status: BCP Aalto University
Expires: August 23, 2012 February 20, 2012 Expires: August 23, 2012 February 20, 2012
Byte and Packet Congestion Notification Byte and Packet Congestion Notification
draft-ietf-tsvwg-byte-pkt-congest-06 draft-ietf-tsvwg-byte-pkt-congest-07
Abstract Abstract
This memo concerns dropping or marking packets using active queue This memo concerns dropping or marking packets using active queue
management (AQM) such as random early detection (RED) or pre- management (AQM) such as random early detection (RED) or pre-
congestion notification (PCN). We give three strong recommendations: congestion notification (PCN). We give three strong recommendations:
(1) packet size should be taken into account when transports read and (1) packet size should be taken into account when transports read and
respond to congestion indications, (2) packet size should not be respond to congestion indications, (2) packet size should not be
taken into account when network equipment creates congestion signals taken into account when network equipment creates congestion signals
(marking, dropping), and therefore (3) the byte-mode packet drop (marking, dropping), and therefore (3) the byte-mode packet drop
skipping to change at page 9, line 51 skipping to change at page 9, line 51
on the size of the packet in question. As the example in Section 1.2 on the size of the packet in question. As the example in Section 1.2
illustrates, to drop any bit with probability 0.1% it is only illustrates, to drop any bit with probability 0.1% it is only
necessary to drop every packet with probability 0.1% without regard necessary to drop every packet with probability 0.1% without regard
to the size of each packet. to the size of each packet.
This approach ensures the network layer offers sufficient congestion This approach ensures the network layer offers sufficient congestion
information for all known and future transport protocols and also information for all known and future transport protocols and also
ensures no perverse incentives are created that would encourage ensures no perverse incentives are created that would encourage
transports to use inappropriately small packet sizes. transports to use inappropriately small packet sizes.
What this advice means for the case of TCP: What this advice means for the case of RED:
1. AQM algorithms such as RED SHOULD NOT use byte-mode drop, which 1. AQM algorithms such as RED SHOULD NOT use byte-mode drop, which
deflates RED's drop probability for smaller packet sizes. RED's deflates RED's drop probability for smaller packet sizes. RED's
byte-mode drop has no enduring advantages. It is more complex, byte-mode drop has no enduring advantages. It is more complex,
it creates the perverse incentive to fragment segments into tiny it creates the perverse incentive to fragment segments into tiny
pieces and it reopens the vulnerability to floods of small- pieces and it reopens the vulnerability to floods of small-
packets that drop-tail queues suffered from and AQM was designed packets that drop-tail queues suffered from and AQM was designed
to remove. to remove.
2. If a vendor has implemented byte-mode drop, and an operator has 2. If a vendor has implemented byte-mode drop, and an operator has
skipping to change at page 11, line 5 skipping to change at page 11, line 5
packet. packet.
Therefore, the IETF transport area should continue its programme of; Therefore, the IETF transport area should continue its programme of;
o updating host-based congestion control protocols to take account o updating host-based congestion control protocols to take account
of packet size of packet size
o making transports less sensitive to losing control packets like o making transports less sensitive to losing control packets like
SYNs and pure ACKs. SYNs and pure ACKs.
Corollaries: What this advice means for the case of TCP:
1. If two TCP flows with different packet sizes are required to run 1. If two TCP flows with different packet sizes are required to run
at equal bit rates under the same path conditions, this should be at equal bit rates under the same path conditions, this should be
done by altering TCP (Section 4.2.2), not network equipment (the done by altering TCP (Section 4.2.2), not network equipment (the
latter affects other transports besides TCP). latter affects other transports besides TCP).
2. If it is desired to improve TCP performance by reducing the 2. If it is desired to improve TCP performance by reducing the
chance that a SYN or a pure ACK will be dropped, this should be chance that a SYN or a pure ACK will be dropped, this should be
done by modifying TCP (Section 4.2.3), not network equipment. done by modifying TCP (Section 4.2.3), not network equipment.
skipping to change at page 28, line 45 skipping to change at page 28, line 45
www.statslab.cam.ac.uk/~frank/ www.statslab.cam.ac.uk/~frank/
evol.html>. evol.html>.
[I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I., [I-D.ietf-avtcore-ecn-for-rtp] Westerlund, M., Johansson, I.,
Perkins, C., O'Hanlon, P., and K. Perkins, C., O'Hanlon, P., and K.
Carlberg, "Explicit Congestion Carlberg, "Explicit Congestion
Notification (ECN) for RTP over UDP", Notification (ECN) for RTP over UDP",
draft-ietf-avtcore-ecn-for-rtp-06 draft-ietf-avtcore-ecn-for-rtp-06
(work in progress), February 2012. (work in progress), February 2012.
[I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., Moncaster, [I-D.ietf-conex-concepts-uses] Briscoe, B., Woundy, R., and A.
T., and J. Leslie, "ConEx Concepts Cooper, "ConEx Concepts and Use
and Use Cases", Cases",
draft-ietf-conex-concepts-uses-00 draft-ietf-conex-concepts-uses-03
(work in progress), November 2010. (work in progress), October 2011.
[IOSArch] Bollapragada, V., White, R., and C. [IOSArch] Bollapragada, V., White, R., and C.
Murphy, "Inside Cisco IOS Software Murphy, "Inside Cisco IOS Software
Architecture", Cisco Press: CCIE Architecture", Cisco Press: CCIE
Professional Development ISBN13: 978- Professional Development ISBN13: 978-
1-57870-181-0, July 2000. 1-57870-181-0, July 2000.
[PktSizeEquCC] Vasallo, P., "Variable Packet Size [PktSizeEquCC] Vasallo, P., "Variable Packet Size
Equation-Based Congestion Control", Equation-Based Congestion Control",
skipping to change at page 39, line 5 skipping to change at page 39, line 5
across different size flows [Rate_fair_Dis]. across different size flows [Rate_fair_Dis].
Appendix D. Changes from Previous Versions Appendix D. Changes from Previous Versions
To be removed by the RFC Editor on publication. To be removed by the RFC Editor on publication.
Full incremental diffs between each version are available at Full incremental diffs between each version are available at
<http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/> <http://tools.ietf.org/wg/tsvwg/draft-ietf-tsvwg-byte-pkt-congest/>
(courtesy of the rfcdiff tool): (courtesy of the rfcdiff tool):
From -06 to -07:
* A mix-up with the corollaries and their naming in 2.1 to 2.3
fixed.
From -05 to -06: From -05 to -06:
* Primarily editorial fixes. * Primarily editorial fixes.
From -04 to -05: From -04 to -05:
* Changed from Informational to BCP and highlighted non-normative * Changed from Informational to BCP and highlighted non-normative
sections and appendices sections and appendices
* Removed language about consensus * Removed language about consensus
 End of changes. 5 change blocks. 
8 lines changed or deleted 13 lines changed or added

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