RecvChunkECNEcho.seq - ECN-ECHO chunk is received to notify IP datagram marked with the CE bit
To check that if a ECN-ECHO chunk is received in ESTABLISHED state, the
endpoint will send ECN_CWR chunk to reponse the ECN-ECHO chunk, and the
congestion control window of endpoint is changed to max(cwnd/2, 4*MTU).
./RecvChunkECNEcho.seq [-tooloption ...] -pkt ./RecvChunkECNEcho.def
-tooloption : v6eval tool option
See Also: ../common/STD_PKT_COMMON.def
../common/SCTP_COMMON.def
Association is established between endpoint A and B. Arrange data
in endpoint A such that ECN_ECHO chunk is sent to endpoint B.
Endpoint A Endpoint B ULP
(ESTABLISHED) (ESTABLISHED)
<---------------- DATA
ECN_ECHO ----------------->
<---------------- ECN_CWR
SACK ----------------->
TEST DESCRIPTION:
1. Send ECN_ECHO chunk from endpoint A to B after received DATA from
endpoint B.
2. Check A: ECN_CWR chunk is received from endpoint B. And Congestion
control window of endpoint B is max(cwnd/2, 4*MTU).
None
RFC 4960
Appendix A. Explicit Congestion Notification
ECN [RFC3168] describes a proposed extension to IP that details a
method to become aware of congestion outside of datagram loss. This
is an optional feature that an implementation MAY choose to add to
SCTP. This appendix details the minor differences implementers will
need to be aware of if they choose to implement this feature. In
general, [RFC3168] should be followed with the following exceptions.
Negotiation:
[RFC3168] details negotiation of ECN during the SYN and SYN-ACK
stages of a TCP connection. The sender of the SYN sets 2 bits in the
TCP flags, and the sender of the SYN-ACK sets only 1 bit. The
reasoning behind this is to ensure that both sides are truly ECN
capable. For SCTP, this is not necessary. To indicate that an
endpoint is ECN capable, an endpoint SHOULD add to the INIT and or
INIT ACK chunk the TLV reserved for ECN. This TLV contains no
parameters, and thus has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter Type = 32768 | Parameter Length = 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ECN-Echo:
[RFC3168] details a specific bit for a receiver to send back in its
TCP acknowledgements to notify the sender of the Congestion
Experienced (CE) bit having arrived from the network. For SCTP, this
same indication is made by including the ECNE chunk. This chunk
contains one data element, i.e., the lowest TSN associated with the
IP datagram marked with the CE bit, and looks as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=12 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The ECNE is considered a Control chunk.
CWR:
[RFC3168] details a specific bit for a sender to send in the header
of its next outbound TCP segment to indicate to its peer that it has
reduced its congestion window. This is termed the CWR bit. For
SCTP, the same indication is made by including the CWR chunk. This
chunk contains one data element, i.e., the TSN number that was sent
in the ECNE chunk. This element represents the lowest TSN number in
the datagram that was originally marked with the CE bit.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Chunk Type=13 | Flags=00000000| Chunk Length = 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lowest TSN Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The CWR is considered a Control chunk.