forked from Minki/linux
4c47af4d5e
Problem statement: 1) both paths (primary path1 and alternate path2) are up after the association has been established i.e., HB packets are normally exchanged, 2) path2 gets inactive after path_max_retrans * max_rto timed out (i.e. path2 is down completely), 3) now, if a transmission times out on the only surviving/active path1 (any ~1sec network service impact could cause this like a channel bonding failover), then the retransmitted packets are sent over the inactive path2; this happens with partial failover and without it. Besides not being optimal in the above scenario, a small failure or timeout in the only existing path has the potential to cause long delays in the retransmission (depending on RTO_MAX) until the still active path is reselected. Further, when the T3-timeout occurs, we have active_patch == retrans_path, and even though the timeout occurred on the initial transmission of data, not a retransmit, we end up updating retransmit path. RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under 6.4.1. "Failover from an Inactive Destination Address" the following: Some of the transport addresses of a multi-homed SCTP endpoint may become inactive due to either the occurrence of certain error conditions (see Section 8.2) or adjustments from the SCTP user. When there is outbound data to send and the primary path becomes inactive (e.g., due to failures), or where the SCTP user explicitly requests to send data to an inactive destination transport address, before reporting an error to its ULP, the SCTP endpoint should try to send the data to an alternate __active__ destination transport address if one exists. When retransmitting data that timed out, if the endpoint is multihomed, it should consider each source-destination address pair in its retransmission selection policy. When retransmitting timed-out data, the endpoint should attempt to pick the most divergent source-destination pair from the original source-destination pair to which the packet was transmitted. Note: Rules for picking the most divergent source-destination pair are an implementation decision and are not specified within this document. So, we should first reconsider to take the current active retransmission transport if we cannot find an alternative active one. If all of that fails, we can still round robin through unkown, partial failover, and inactive ones in the hope to find something still suitable. Commit |
||
|---|---|---|
| .. | ||
| 9p | ||
| 802 | ||
| 8021q | ||
| appletalk | ||
| atm | ||
| ax25 | ||
| batman-adv | ||
| bluetooth | ||
| bridge | ||
| caif | ||
| can | ||
| ceph | ||
| core | ||
| dcb | ||
| dccp | ||
| decnet | ||
| dns_resolver | ||
| dsa | ||
| ethernet | ||
| hsr | ||
| ieee802154 | ||
| ipv4 | ||
| ipv6 | ||
| ipx | ||
| irda | ||
| iucv | ||
| key | ||
| l2tp | ||
| lapb | ||
| llc | ||
| mac80211 | ||
| mac802154 | ||
| mpls | ||
| netfilter | ||
| netlabel | ||
| netlink | ||
| netrom | ||
| nfc | ||
| openvswitch | ||
| packet | ||
| phonet | ||
| rds | ||
| rfkill | ||
| rose | ||
| rxrpc | ||
| sched | ||
| sctp | ||
| sunrpc | ||
| tipc | ||
| unix | ||
| vmw_vsock | ||
| wimax | ||
| wireless | ||
| x25 | ||
| xfrm | ||
| compat.c | ||
| Kconfig | ||
| Makefile | ||
| nonet.c | ||
| socket.c | ||
| sysctl_net.c | ||