• Neil Horman's avatar
    sctp: be more restrictive in transport selection on bundled sacks · 4244854d
    Neil Horman authored
    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: 's avatarNeil 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: 's avatarMichele Baldessari <michele@redhat.com>
    Reported-by: 's avatarsorin serban <sserban@redhat.com>
    Acked-by: 's avatarVlad Yasevich <vyasevich@gmail.com>
    Signed-off-by: 's avatarDavid S. Miller <davem@davemloft.net>
    4244854d
Name
Last commit
Last update
..
Kconfig Loading commit data...
Makefile Loading commit data...
associola.c Loading commit data...
auth.c Loading commit data...
bind_addr.c Loading commit data...
chunk.c Loading commit data...
command.c Loading commit data...
debug.c Loading commit data...
endpointola.c Loading commit data...
input.c Loading commit data...
inqueue.c Loading commit data...
ipv6.c Loading commit data...
objcnt.c Loading commit data...
output.c Loading commit data...
outqueue.c Loading commit data...
primitive.c Loading commit data...
probe.c Loading commit data...
proc.c Loading commit data...
protocol.c Loading commit data...
sm_make_chunk.c Loading commit data...
sm_sideeffect.c Loading commit data...
sm_statefuns.c Loading commit data...
sm_statetable.c Loading commit data...
socket.c Loading commit data...
ssnmap.c Loading commit data...
sysctl.c Loading commit data...
transport.c Loading commit data...
tsnmap.c Loading commit data...
ulpevent.c Loading commit data...
ulpqueue.c Loading commit data...