draft-ietf-sigtran-sctp-01.txt   draft-ietf-sigtran-sctp-02.txt 
skipping to change at line 20 skipping to change at line 20
Nortel Networks Nortel Networks
I. Rytina I. Rytina
Ericsson Ericsson
M. Kalla M. Kalla
Telcordia Telcordia
L. Zhang L. Zhang
UCLA UCLA
V. Paxson V. Paxson
ACIRI ACIRI
expires in six months October 15,1999 expires in six months October 20,1999
Simple Control Transmission Protocol Simple Control Transmission Protocol
<draft-ietf-sigtran-sctp-01.txt> <draft-ietf-sigtran-sctp-02.txt>
Status of This Memo Status of This Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
skipping to change at line 2522 skipping to change at line 2522
discussed in rule C7 above may be used to provide an upper bound discussed in rule C7 above may be used to provide an upper bound
to this doubling operation. to this doubling operation.
E4) Start the retransmission timer, per rule R1 above. E4) Start the retransmission timer, per rule R1 above.
Note, the data sender MAY use a value smaller than the RTO when Note, the data sender MAY use a value smaller than the RTO when
start the retransmission timer IF the sender has fewer than start the retransmission timer IF the sender has fewer than
cwnd octets of outstanding data on the transport address to which cwnd octets of outstanding data on the transport address to which
the retransmission is being sent. the retransmission is being sent.
[Editors Note: if the receiver is multi-homed and the retrans [Editors Note: if the receiver is multi-homed and the retrans
is to be sent to an alternate address, how this rapid retran is to be sent to an alternate address, how this rapid retran
rule should apply??] rule should apply??]
Note that after retransmitting, once a new RTT measurement is obtained Note that after retransmitting, once a new RTT measurement is obtained
(which can only happen when new data has been sent and acknowledged, (which can only happen when new data has been sent and acknowledged,
per rule C5, or for a measurement made from a Heartbeat [see Section per rule C5, or for a measurement made from a Heartbeat [see Section
7.3]), the computation in rule C3 is performed, including the 7.3]), the computation in rule C3 is performed, including the
computation of RTO, which may result in "collapsing" RTO back down computation of RTO, which may result in "collapsing" RTO back down
after it has been subject to doubling (rule E3). after it has been subject to doubling (rule E3).
The final rule for managing the retransmission timer concerns failover: The final rule for managing the retransmission timer concerns failover:
F1) Whenever SCTP switches from the current destination transport F1) Whenever SCTP switches from the current destination transport
address to a different one (per section ???), the current address to a different one (per section 5.4), the current
retransmission timer is left running. As soon as SCTP transmits retransmission timer is left running. As soon as SCTP transmits
a packet containing data to the new transport address, restart the a packet containing data to the new transport address, restart the
timer, using the RTO value for the path to the new address. timer, using the RTO value for the path to the new address.
5.4 Multi-homed SCTP Endpoints 5.4 Multi-homed SCTP Endpoints
An SCTP endpoint is considered multi-homed if there are more than one An SCTP endpoint is considered multi-homed if there are more than one
transport addresses that can be used as a destination address to reach transport addresses that can be used as a destination address to reach
that endpoint. that endpoint.
skipping to change at line 2965 skipping to change at line 2965
keeps a counter for each TSN hole first reported by a SACK; the keeps a counter for each TSN hole first reported by a SACK; the
counter keeps track of whether 3 subsequent SACKs have reported the counter keeps track of whether 3 subsequent SACKs have reported the
same hole. same hole.
Because cwnd in SCTP bounds the number of outstanding TSN's, Because cwnd in SCTP bounds the number of outstanding TSN's,
the effect of TCP fast-recovery is achieved automatically with no the effect of TCP fast-recovery is achieved automatically with no
adjustment to the control window size. [Is this still true??] adjustment to the control window size. [Is this still true??]
6.3 Path MTU Discovery 6.3 Path MTU Discovery
[Editor's Note: text to be provided by Vern] RFC 1191 discusses "Path MTU Discovery", whereby a sender maintains an
estimate of the maximum transmission unit (MTU) along a given Internet path
and refrains from sending datagrams along that path which exceed the MTU,
other than occasional attempts to probe for a change in the path MTU.
RFC 1191 is thorough in its discussion of the MTU discovery mechanism and
strategies for determining the current end-to-end MTU setting as well as
detecting changes in this value. RFC 1981 discusses applying the same
mechanisms for IPv6.
An SCTP sender MUST apply these techniques, and MUST do so on a
per-destination-address basis.
There are 4 ways in which SCTP differs from the description in RFC 1191 of
applying MTU discovery to TCP:
1) SCTP associations can span multiple set of addresses.
Per the above comment, an SCTP sender MUST maintain separate
MTU estimates for each destination address of its peer.
2) Elsewhere in this document, when the term "MTU" is discussed,
it refers to the MTU associated with the destination address
corresponding to the context of the discussion. If this
address is ambiguous, it indicates a bug in this document.
3) Unlike TCP, SCTP does not have a notion of "Maximum Segment
Size". Accordingly, the MTU for each destination address
SHOULD be initialized to a value no larger than the link MTU
for the local interface to which datagrams for that remote
destination address will be routed.
4) Since data transmission in SCTP is naturally structured in
terms of TSNs rather than bytes (as is the case for TCP), the
discussion in section 6.5 of RFC 1191 applies: when retransmitting
a datagram to a remote address for which the datagram appears
too large for the path MTU to that address, the datagram SHOULD
be retransmitted without the DF bit set, allowing it to possibly
be fragmented. Transmissions of new datagrams MUST have DF set.
Other than these differences, the discussion of TCP's use of MTU discovery
in RFCs 1191 and 1981 applies to SCTP, too, on a per-destination-address
basis.
6.4 Discussion 6.4 Discussion
[The following discussion needs to be updated for byte-based algorithm] [The following discussion needs to be updated for byte-based algorithm]
There is one important difference between the SCTP congestion control, There is one important difference between the SCTP congestion control,
as described above, and TCP congestion control. In the latter the as described above, and TCP congestion control. In the latter the
control behavior is measured in unit of packets. That is, upon slow control behavior is measured in unit of packets. That is, upon slow
start, a TCP connection doubles cwnd value per RTT as measured by the start, a TCP connection doubles cwnd value per RTT as measured by the
number of packets. In SCTP, cwnd value is doubled per RTT as measured number of packets. In SCTP, cwnd value is doubled per RTT as measured
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/