Guidelines for Internet Congestion Control at Endpoints
draft-fairhurst-tsvwg-cc-02

Abstract

This document provides guidance on the design of methods to avoid congestion collapse and to provide congestion control. Recommendations and requirements on this topic are distributed across many documents in the RFC series. This therefore seeks to gather and consolidate these recommendations. This is intended to provide input to the design of new congestion control methods in protocols, such as IETF QUIC.

The present document is for discussion and comment by the IETF.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on January 27, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. Terminology
• 3. Principles of Congestion Control
• 3.1. A Diversity of Path Characteristics
• 3.2. Flow Multiplexing and Congestion
• 3.3. Avoiding Congestion Collapse
• 4. Guidelines for Performing Congestion Control
• 4.1. Connection Initialization
• 4.2. Using Path Capacity
• 4.3. Timers and Retransmission
• 4.4. Responding to Potential Congestion
• 4.5. Using More Capacity
• 4.6. Network Signals
• 4.7. Protection of Protocol Mechanisms
• 5. IETF Guidelines on Evaluation of Congestion Control
• 6. Acknowledgements
• 7. IANA Considerations
• 8. Security Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Revision Notes
• Author's Address

1. Introduction

The IETF has specified Internet transports (e.g., TCP [ID.ietf-tcpm-rfc793bis], UDP [RFC0768], UDP-Lite [RFC3828], SCTP [RFC4960], and DCCP [RFC4340]) as well as protocols layered on top of these transports (e.g., RTP, QUIC [I-D.ietf-quic-transport], SCTP/UDP [RFC6951], DCCP/UDP) and transports that work directly over the IP network layer. These transports are implemented in endpoints (Internet hosts or routers acting as endpoints) and are designed to detect and react to network congestion.

Recommendations and requirements on this topic are distributed across many documents in the RFC series. This document therefore seeks to gather and consolidate these recommendations. This is intended to provide input to the design of new congestion control methods in protocols.

2. Terminology

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 [RFC2119].

The path between endpoints (sometimes called "Internet Hosts") consists of the endpoint protocol stack at the sender and receiver (which implements the transport service), and a succession of links and network devices (routers or middleboxes) that provide connectivity across the network. The set of network devices forming the path is not usually fixed, and it should generally be assumed that this set can change over arbitrary lengths of time.

Other terminology is directly copied from the cited RFCs.

3. Principles of Congestion Control

This section summarises the principles for providing congestion control, and provides the background for section Section 4.

3.1. A Diversity of Path Characteristics

Internet transports do not usually rely upon prior reservation of capacity along the path they use. In the absence of such a resource reservation, endpoints are unable to determine a safe rate at which to start or continue their transmission. The use of an Internet path therefore requires a combination of end-to-end transport mechanisms to detect and then respond to changes in the capacity that it discovers is available across the network path. Buffering (an increase in latency) or loss (discard of a packet) arises when the traffic arriving at a link or network exceeds the resources available.

A network device that does not support Active Queue Management (AQM) [RFC7567] typically uses a drop-tail policy to drop excess IP packets when its queue becomes full. Although losses are not always due to congestion (loss may be due to link corruption, receiver overrun, etc. [RFC3819]), endpoint congestion control has to conservatively assume that any loss is potentially due to congestion and then reduce the sending rate of their flows to reflect the available capacity.

The use of a path to send packets impacts any flows (possibly from or to other endpoints) that share the capacity of a common network device or link (i.e., are (i.e., multiplexed) . As with loss, latency can also be incurred for other reasons [RFC3819] (Quality of Service link scheduling, link radio resource management/bandwidth on demand, transient outages, link retransmission, and connection/resource setup below the IP layer, etc).

Principles include:

• A design is REQUIRED be robust to a change in the set of devices forming the network path. A reconfiguration, reset or other event could interrupt this path or trigger a change in the set of network devices forming the path.
• Transports are REQUIRED to operate safely over the wide range of path characteristics presented by Internet paths.
• The path characteristics can change over relatively short intervals of time (i.e., characteristics discovered do not necessarily remain valid for multiple Round Trip Times, RTTs). In particular, a sender SHOULD measure and adapt to the characteristics of the path(s) they use.

3.2. Flow Multiplexing and Congestion

It is normal to observe some perturbation in latency and/or loss when flows shares a common network bottleneck with other traffic. This impact needs to be considered and Internet flows ought to implement appropriate safeguards to avoid inappropriate impact on other flows that share the resources along a path. Congestion control methods satisfy this requirement and therefore can help avoid congestion collapse [@ARTICLE{author = {Bob Briscoe}, title = {Flow Rate Fairness: Dismantling a Religion}, journal = {ACM CCR}, year = {2007} }].

An endpoint can become aware of congestion by various means. A signal that indicates congestion on the end-to-end network path, needs to result in a congestion control reaction by the transport to reduce the maximum rate permitted by the sending endpoint [RFC8087]]. Internet transports should react to avoid congestion that impacts other flows sharing a path, and need to be designed to avoid starving other flows of capacity. This could include methods seeking to equally distribute resources between sharing flows, but this is explicitly not a requirement for a network device.

The Requirements for Internet Hosts formally mandates that endpoints perform congestion control. "Because congestion control is critical to the stable operation of the Internet, applications and other protocols that choose to use UDP as an Internet transport must employ mechanisms to prevent congestion collapse and to establish some degree of fairness with concurrent traffic [RFC2914]. They may also need to implement additional mechanisms, depending on how they use UDP" [RFC8085]. [RFC2309] also discussed the dangers of congestion-unresponsive flows, and states that "all UDP-based streaming applications should incorporate effective congestion avoidance mechanisms." [RFC7567] and [RFC8085] reaffirm this.

The general recommendation in the UDP Guidelines [RFC8085] is that applications SHOULD leverage existing congestion control techniques, such as those defined for TCP [RFC5681], TFRC [RFC5348], SCTP [RFC4960], and other IETF-defined transports. This is because there are many trade offs and details that can have a serious impact on the performance of congestion control for the application they support and other traffic that seeks to share the resources along the path over which they communicate.

Experience has shown that successful protocols developed in a specific context or for a particular application tend to also become used in a wider range of contexts. Therefore, IETF specifications by default target deployment on the general Internet, or need to be defined for use only within a controlled environment.

Principles include:

• Endpoints MUST perform congestion control [RFC1122] .
• Transports MUST avoid inducing flow starvation to other flows that share resources along the path they use.
• "If an application or protocol chooses not to use a congestion-controlled transport protocol, it SHOULD control the rate at which it sends UDP datagrams to a destination host, in order to fulfil the requirements of [RFC2914]", as stated in [RFC8085].
• Transports that do not target Internet deployment need to be constrained to only operate in a controlled environment (e.g. see Section 3.6 of [RFC8085]) and provide appropriate mechanisms to prevent traffic accidentally leaving the controlled environment [RFC8084].

3.3. Avoiding Congestion Collapse

A significant pathology can arise when a poorly designed transport creates congestion. This can result in severe service degradation or "Internet meltdown". This phenomenon was first observed during the early growth phase of the Internet in the mid 1980s [RFC896] [RFC970]; it is technically called "congestion collapse" and was a key focus of [RFC2309].

• Endpoints MUST control their flows to avoid Congestion Collapse.
• A sender SHOULD measure and adapt protocol timers to the measured the path RTT.
• When a endpoint detects persitent congestion, it MUST employ exponential backoff to the maximum rate (i.e. reduce its congestion window).
• Endpoints MUST treat a loss of all feedback (e.g., RTO expiry) as an indication of persisent congestions (an indication of potential congestion collapse), until the path characteristics can again be confirmed.
• Network devices can provide mechanisms to mitigate the impact of congestion collapse by transport flows (e.g., priority forwarding of control information, and starvation detection) to mitigate the impact of non-conformant and malicious flows [RFC7567]).

4. Guidelines for Performing Congestion Control

This section provides guidance for designers of a new transport protocol that decide to implement congestion control and its associated mechanisms.

4.1. Connection Initialization

When a connection or flow to a new destination is established, the endpoints have little information about the characteristics of the network path. This section describes how a flow starts transmission over such a path.

Flow Start:

A new flow between two endpoints cannot assume that capacity is available at the start of the flow, unless it uses a mechanism to explicitly reserve capacity. In the absence of a capacity signal, a flow MUST therefore start slowly.

The slow-start algorithm is the accepted standard for flow startup [RFC5681]. TCP uses the notion of an Initial Window (IW [RFC3390] updated by [RFC6928]) to define the initial volume of data that can be sent on a path. This is not the smallest burst, or the smallest window - but it is considered a safe starting point for a network that is not suffering persistent congestion, and applicable until feedback about the path is received. This initial sending rate needs to be viewed as tentative until the capacity is confirmed to be available.

Initial RTO Interval:

When a flow sends the first packet it typically has no way to know the actual RTT of the path it uses. The initial value used to the principal retransmission timer, used to detect lack of responsiveness from the remote endpoint. In TCP this is the starting value of the Retransmission Timeout (RTO), or corresponding timer in another protocol. The initial value is therefore a trade off that has important consequences on the overall Internet stability [RFC6928] [RFC8085]. In the absence of any knowledge about the latency of a path, the RTO MUST be conservatively set to no less than 1 second. Values shorter than 1 second can be problematic (see the appendix of [RFC6298]). (Note: Linux TCP has deployed a smaller initiaL RTO value)

Initial RTO Expiry:

If the RTO timer expires while awaiting completion of the connection setup (in TCP, the ACK of a SYN segment), and the implementation is using an RTO less than 3 seconds, the local endpoint can resend the connection setup. The RTO MUST then be re-initialized to increase it to 3 seconds when data transmission begins (i.e., after the three-way handshake completes) [RFC6298] [RFC8085]. This conservative increase is necessary to avoid congestion collapse when many flows retransmit across a shared bottleneck with restricted capacity.

Initial Measured RTO:

Once an RTT measurement is available (e.g., through reception of an acknowledgement), this value must be adjusted, and MUST take into account the RTT variance. For the first sample, this variance cannot be determined, and a local endpoint must therefore initialise the variance to RTT/2 (see equation 2.2 of [RFC6928] and related text for UDP in section 3.1.1 of [RFC8085]).

Current State:

A congestion controller MAY assume that recently used capacity between a pair of endpoints is an indication of future capacity available in the next RTT between the same endpoints. It must react (reduce its rate) if this is not confirmed to be true.

Cached State:

A congestion controller that recently used a specific path could use additional state that lets a flow take-over the capacity that was previously consumed by another flow (e.g., in the last RTT) which it understands is using the same path, or which was recently using that path. In TCP, this mechanism is referred to as TCP Control Block (TCB) sharing [RFC2140] [ID.ietf-tcpm-2140bis]. The capacity and other information can be used to suggest a faster initial sending rate, but this information MUST be viewed as tentative until it is confirmed by receiving confirmation that actual traffic has been sent across the path. A sender MUST reduce its rate if this capacity is not confirmed within the current RTO interval.

4.2. Using Path Capacity

This section describes how a sender needs to regulate the maximum volume of data in flight over the interval of the current RTT, and how it manages transmission of the capacity that it perceives is available.

Congestion Management:

The capacity available to a flow could be expressed as the number of bytes in flight, the sending rate or a limit on the number of unacknowledged segments. In steady-state this congestion window reflects a safe limit to the sending rate that has not resulted in persistent congestion. A sender performing congestion management will usually optimise performance for its application by avoiding excessive loss or delay.

One common model views the path between two endpoints as a pipe. New packets enter the pipe at the sending endpoint, older ones leave at the receiving endpoint. Received data (leaviung the network path) is usually acknowledged to the sender. The rate that data leaves the pipe indicates the share of the capacity that has been utilised by the flow. If, on average (over an RTT), the sending rate equals the receiving rate, this indicates that this capacity can be safely used again in the next RTT. If the average receiving rate is less than the sending rate, then the path is either queuing packets, the RTT/path has changed, or there is packet loss.

Transient Path:

Path capacity information is transient. A sender that fails to use capacity has no understanding whether that previously used capacity remains available to use - or whether it has disappeared (e.g., to a change to a path with a smaller bottleneck, or more traffic has emerged that has consumed the previously available capacity). For this reason, a sender that is limited by the volume of data available to send MUST NOT continue to grow the congestion window [RFC5681].

Standard TCP states that a TCP sender SHOULD set the congestion window to no more than the Restart Window (R) before beginning transmission if the TCP sender has not sent data in an interval that exceeds the current retransmission timeout, i.e., when an application becomes idle [RFC5681]. Experimental specifications permit TCP senders to tentatively maintain a congestion window when application-limited, provided that they appropriately and rapidly collapse the window when potential congestion is detected [RFC7661]. This mechanism is called Congestion Window Validation (CWV).

Burst Mitigation:

Even in the absence of congestion, statistical multiplexing of flows can result in transient effects for flows sharing common resources. A sender therefore SHOULD avoid inducing excessive congestion to other flows (collateral damage).

While a congestion controller ought to limit sending at the granularity of the current RTT, this can be insufficient to satisfy the goals of preventing starvation and mitigating collateral damage. This requires moderating the burst rate of the sender to avoid significant periods where a flow(s) consume all buffer capacity at the path bottleneck, which would otherwise prevent other flows from gaining a reasonable share.

Endpoints SHOULD provide mechanisms to regulate the bursts of transmission that the application/protocol sends to the network (section 3.1.6 of [RFC8085]). ACK-Clocking [RFC5681] can help mitigate bursts for protocols that receive continuous feedback of reception (such as TCP). Sender pacing can mitigate this [RFC8085], (See Section 4.6 of [RFC3449]), and has been recommended for TCP in conditions where ACK-Clocking is not effective, (e.g., [RFC3742], [RFC7661]). SCTP [RFC4960] defines a maximum burst length (Max.Burst) with a recommended value of 4 segments to limit the SCTP burst size.

4.3. Timers and Retransmission

This section describes mechanisms to detect and provide retransmission, and to protect the network in the absence of timely feedback.

Loss Detection:

Loss detection occurs after a sender determines there is no delivery confirmation within an expected period of time (e.g. by observing the time-ordering of the reception of ACKs, as in TCP DupACK) or by utilising a timer to detect loss (e.g. a transmission timer with a period less than the RTO, [RFC8085] [ID.ietf-tcpm-rack]) or a combination of using a timer and ordering information to trigger retransmission of data.

Retransmission:

Retransmission of lost packets or messages is a common reliability mechanism. When loss is detected, the sender can choose to retransmit the lost data, ignore the loss, or send other data. Any transmission consumes network capacity, therefore retransmissions MUST NOT increase the network load in response to congestion loss (which worsens that congestion) [RFC8085]. Any method that sends additional data following loss is responsible for congestion control of the retransmissions (and any other packets sent) as well as the original traffic.

Measuring the RTT:

Once an endpoint has started communicating with its peer, the RTT be MUST adjusted by measuring the actual path RTT and its variance (see equation 2.3 of [RFC6928]).

Maintaining the RTO:

The RTO SHOULD be set based on recent RTT observations [RFC8530].

RTO Expiry:

Persistent lack of feedback (e.g. detected by the RTO timer, or other means) MUST be treated an indication of potential congestion collapse. A failure to receive any specific response within a RTO interval could potentially be a result of a RTT change, change of path, excessive loss, or even congestion collapse. If there is no response within the RTO interval, TCP collapses the congestion window to one segment [RFC5681]. Other transports must similarly respond when they detect loss of feedback.

An endpoint needs to exponentially backoff the RTO interval [RFC8085] each time the RTO expires. That is the RTO interval MUST be set to the RTO * 2 [RFC6298] [RFC8085].

Maximum RTO:

A maximum value MAY be placed on the RTO interval. The maximum limit to the RTO interval MUST NOT be less than 60 seconds [RFC6298].

4.4. Responding to Potential Congestion

Internet flows SHOULD implement appropriate safeguards to avoid inappropriate impact on other flows that share the resources along a path. The safety and responsiveness of new proposals need to be evaluated [RFC5166]. In determining an appropriate congestion response, designs could take into consideration the size of the packets that experience congestion [RFC4828].

Congestion Response:

An endpoint MUST promptly reduce the rate of transmission when it receive or detects an indication of congestion (e.g. loss) [RFC2914].

TCP Reno established a method that relies on multiplicative-decrease to halve the sending rate while congestion is detected. This response to congestion indications is considered sufficient for safe Internet operation, but other decrease factors have also been published in the RFC Series [RFC8312].

ECN Response:

A congestion control design should provide the necessary mechanisms to support Explicit Congestion Notification (ECN) [RFC3168] [RFC6679], as described in section 3.1.7. of [RFC8085]. This can help determine an appropriate congestion window when supported by routers on the path [RFC7567] to enable rapid early indication of incipient congestion.

The early detection of incipient congestion justifies a different reaction to packet loss to that for the congestion signal [RFC8311] [RFC8087]]. Simple feedback of received Congestion Experienced (CE) marks [RFC3168], relies only on an indication that congestion has been experienced within the last RTT. This style of response is appropriate when a flow uses ECT(0). The reaction to reception of this indication was modified in TCP ABE [RFC8511]. Further detail about the received CE-marking can be obtained by using more accurate receiver feedback (e.g. [ID.-ietf-tcpm-accurate-ecn] and extended RTP feedback). The more detailed feedback provides an opportunity for a finer-granularity of congestion response.

Current work-in-progress [ID.ietf-tsvwg-l4s-arch] defines a reaction for packets marked with ECT(1), building on the style of detailed feedback provided by [ID.-ietf-tcpm-accurate-ecn] and a modified marking system [ID.ietf-tsvwg-aqm-dualq-coupled].

Robustness to Path Change:

The detection of congestion and the resulting reduction MUST NOT solely depend upon reception of a signal from the remote endpoint, because congestion indications could themselves be lost under persistent congestion.

The only way to surely confirm that a sending endpoint has successfully communicated with a remote endpoint is to utilise a timer (see) to detect a lack of response that could result from a change in the path or the path characteristics (usually called the RTO). Congestion controllers that are unable to react after one (or at most a few) RTTs after receiving a congestion indication should observe the guidance in section 3.3 of the UDP Guidelines [RFC8085].

Persistent Congestion:

Persistent congestion can result in congestion collapse, which MUST be aggressively avoided [RFC2914]. Endpoints that experience persistent congestion and have already exponentially reduced their congestion window to the restart window (e.g., 1 packet), MUST further reduce the rate if the RTO timer continues to expire. For example, TCP-Friendly Rate Control (TFRC) [RFC5348] continues to reduce its sending rate under persistent congestion to one packet per RT, and then exponentially backs off the time between single packet transmissions if the congestion continues to persist [RFC2914].

[RFC8085] provides guidelines for a sender that does not, or is unable to, adapt the congestion window.

4.5. Using More Capacity

In the absence of persistent congestion, an endpoint is permitted to increase its congestion window and hence the sending rate. An increase should only occur when there is additional data available to send across the path (i.e., the sender will utilise the additional capacity in the next RTT).

TCP Reno [RFC5681] defines an algorithm, known as the AIMD (additive-increase/ multiplicative-decrease) that allows a sender to exponentially increase the congestion window each RTT from the initial window to the first detected congestion event. This is designed to allow new flows to rapidly acquire a suitable congestion window. Where the bandwidth delay product (BDP) is large, it can take many RTTs to determine a suitable share of the path capacity. Such high BDP paths benefit from methods that more rapidly increase the congestion window, but in compensation these need to be designed to also react rapidly to any detected congestion (e.g., TCP Cubic [RFC8312]).

Increasing Congestion Window:

A sender MUST NOT continue to increase its rate for more than an RTT after a congestion indication is received. It SHOULD stop increasing its congestion window as soon as it receives indication of congestion to avoid excessive "overshoot".

While the sender is increasing the congestion window, a sender will transmit faster than the last known safe rate. Any increase above the last confirmed rate needs to be regarded as tentative and the sender reduce their rate below the last confirmed safe rate when congestion is experienced (a congestion event).

Congestion:

An endpoint MUST utilise a method that assures the sender will keep the rate below the previously confirmed safe rate for multiple RTTs after an observed congestion event. In TCP, this is performed by using a linear increase from a slow start threshold that is re-initialised when congestion is experienced.

Avoiding Overshoot:

Overshoot of the congestion window beyond the point of congestion can significantly impact other flows sharing resources along a path. It is important to note that as endpoints experience more paths with a large BDP and a wider range of potential path RTT, that variability or changes in the path can have very significant constraints on appropriate dynamics for increasing the congestion window (see also burst mitigation Section 4.2).

4.6. Network Signals

An endpoint can utilise signals from the network to help determine how to regulate the traffic it sends.

Network Signals:

Mechanisms MUST NOT solely rely on messages or other specific signalling messages to perform safely. (See section 5.2 of [RFC8085] describing use of ICMP messages). The path characteristics can change at any time. Transport mechanisms need to be robust to potential black-holing of any signals (i.e., need to be robust to loss or modification of packets).

A mechanism that utilises signals originating in the network (e.g. RSVP, NSIS, Quick-Start, ECN), must assume that the set of network devices on the path can change. This motivates the use of soft-state when designing protocols that interact with signals originating from network devices [panrg] (e.g., ECN). This can include context-sensitive treatment of "soft" signals provided to the endpoint [RFC5461].

4.7. Protection of Protocol Mechanisms

An endpoint needs to provide protection from attacks on the traffic it generates, or attacks that seek to increase the capacity it consumes (impacting other traffic that shared a bottleneck).

Off Path Attack:

A design MUST protect from off-path attack to the protocol [RFC8085]. An attack on the congestion control can lead to a DoS vulnerability for the flow being controlled and/or other flows that share network resources along the path.

Validation of Signals:

Network signalling and control messages (e.g., ICMP [RFC0792]) MUST be validated before they are used to protect from malicious abuse. This MUST at least include protection from off-path attack [RFC8085].

On Path Attack:

A protocol can be designed to protect from on-path attacks, but this requires more complexity and the use of encryption/authentication mechanisms (e.g., IPsec [RFC4301], QUIC [I-D.ietf-quic-transport]).

5. IETF Guidelines on Evaluation of Congestion Control

The IETF has provided guidance [RFC5033] for considering alternate congestion control algorithms. The IRTF has described a set of metrics and related trade-off between metrics that can be used to compare, contrast, and evaluate congestion control techniques [RFC5166].

6. Acknowledgements

Nicholas Kuhn helped develop the first draft of these guidelines. Tom Jones reviewed the first version of this draft. Gorry Fairhurst and Tom Jones were funded at the University of Aberdeen by the European Space Agency. Ana Custura helped review the text.

The views expressed are solely those of the author(s).

7. IANA Considerations

This memo includes no request to IANA.

RFC Editor Note: If there are no requirements for IANA, the section will be removed during conversion into an RFC by the RFC Editor.

8. Security Considerations

The security considerations for the use of transports are provided in the references section of the cited RFCs. Security guidance for applications using UDP is provided in the UDP Usage Guidelines [RFC8085].

Section Section 4.6 supports current best practice to validate ICMP messages prior to use. Section Section 4.7 describes general requirements relating to the design of safe protocols and their protection from on and off path attack.

9. References

9.1. Normative References

9.2. Informative References

Appendix A. Revision Notes

Note to RFC-Editor: please remove this entire section prior to publication.

Individual draft -00:

• Comments and corrections are welcome directly to the authors or via the IETF TSVWG, working group mailing list.

Individual draft -01:

• This update is proposed for initial WG comments.
• If there is interest in progressing this document, the next version will include more complee referencing to citred material.

Individual draft -02:

• Correction of typos.

Author's Address