On Thu, Jun 30, 2011 at 10:08:40AM -0400, Vladislav Yasevich wrote: > How about this. If we in SHUTDOWN_PENDING state, let the errors accumulate upto > max_retrans. After that, start SHUTDOWN_GUARD timer to let the association live a > bit longer just on the off-chance the receive comes back. When SHUTDOWN_GUARD > expires it will abort the association. > > When we are in this state, SACK processing will have to reset SHUTDOWN_GUARD when > the SACK is actually acknowledging something. Good idea. I'll update my patch. > > > > What sideeffects are you worried about resulting from my proposal? > > > > There is a potential that the sender may abort prematurely. The issue is that > the sender has no way of knowing if the remote process somehow terminated and > will never consume data, or if it is just extremely busy with something else and > will come back. Since this is a reliable protocol, we given the receive the benefit > of the doubt and try our hardest to get the data across. Understood although we are talking 10 * RTO here without an actual SACK. > My suggestion above is still a bit of a hack that one could argue still violates the > protocol, but the time period tries to remove as much doubt from the sender as possible > the the receiver is really out-to-lunch. Assuming that by 'shutdown sequence' the spec is only referring to the SHUTDOWN / SHUTDOWN ACK exchange it would still violate the protocol but I don't see how to avoid having association hang around forever without violating the spec. This really looks like a hole in the spec to me. -- 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
