aboutsummaryrefslogtreecommitdiffstats
path: root/net/sctp/ulpqueue.c
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2012-06-29 23:04:26 -0400
committerDavid S. Miller <davem@davemloft.net>2012-07-01 01:44:35 -0400
commit4244854d22bf8f782698c5224b9191c8d2d42610 (patch)
tree1c6d81517625a33e427a183587783a966960e135 /net/sctp/ulpqueue.c
parent0e90b49ca4b891f085b57559a3071a4feefb496c (diff)
sctp: be more restrictive in transport selection on bundled sacks
It was noticed recently that when we send data on a transport, its possible that we might bundle a sack that arrived on a different transport. While this isn't a major problem, it does go against the SHOULD requirement in section 6.4 of RFC 2960: An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK, etc.) to the same destination transport address from which it received the DATA or control chunk to which it is replying. This rule should also be followed if the endpoint is bundling DATA chunks together with the reply chunk. This patch seeks to correct that. It restricts the bundling of sack operations to only those transports which have moved the ctsn of the association forward since the last sack. By doing this we guarantee that we only bundle outbound saks on a transport that has received a chunk since the last sack. This brings us into stricter compliance with the RFC. Vlad had initially suggested that we strictly allow only sack bundling on the transport that last moved the ctsn forward. While this makes sense, I was concerned that doing so prevented us from bundling in the case where we had received chunks that moved the ctsn on multiple transports. In those cases, the RFC allows us to select any of the transports having received chunks to bundle the sack on. so I've modified the approach to allow for that, by adding a state variable to each transport that tracks weather it has moved the ctsn since the last sack. This I think keeps our behavior (and performance), close enough to our current profile that I think we can do this without a sysctl knob to enable/disable it. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: Vlad Yaseivch <vyasevich@gmail.com> CC: David S. Miller <davem@davemloft.net> CC: linux-sctp@vger.kernel.org Reported-by: Michele Baldessari <michele@redhat.com> Reported-by: sorin serban <sserban@redhat.com> Acked-by: Vlad Yasevich <vyasevich@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'net/sctp/ulpqueue.c')
-rw-r--r--net/sctp/ulpqueue.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index f2d1de7f2ffb..f5a6a4f4faf7 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -1051,7 +1051,7 @@ void sctp_ulpq_renege(struct sctp_ulpq *ulpq, struct sctp_chunk *chunk,
1051 if (chunk && (freed >= needed)) { 1051 if (chunk && (freed >= needed)) {
1052 __u32 tsn; 1052 __u32 tsn;
1053 tsn = ntohl(chunk->subh.data_hdr->tsn); 1053 tsn = ntohl(chunk->subh.data_hdr->tsn);
1054 sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn); 1054 sctp_tsnmap_mark(&asoc->peer.tsn_map, tsn, chunk->transport);
1055 sctp_ulpq_tail_data(ulpq, chunk, gfp); 1055 sctp_ulpq_tail_data(ulpq, chunk, gfp);
1056 1056
1057 sctp_ulpq_partial_delivery(ulpq, chunk, gfp); 1057 sctp_ulpq_partial_delivery(ulpq, chunk, gfp);