From: Neil Horman <nhorman@xxxxxxxxxxxxx> Date: Sat, 30 Jun 2012 09:04:26 -0400 > 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@xxxxxxxxxxxxx> > CC: Vlad Yaseivch <vyasevich@xxxxxxxxx> > CC: David S. Miller <davem@xxxxxxxxxxxxx> > CC: linux-sctp@xxxxxxxxxxxxxxx > Reported-by: Michele Baldessari <michele@xxxxxxxxxx> > Reported-by: sorin serban <sserban@xxxxxxxxxx> Once this has Vlad's ACK I'll apply it. There has to be a better way to handle this situation, wherein the responsible party has ACK'd the patch but I just ask for a few coding style fixups and whatnot. As it stands now I have to twiddle my thumbs waiting for the new ACK. -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
