On 10/30/12 at 10:21am, Vlad Yasevich wrote: > What if the message arrived across multiple transports? > > Also, you can always see current rto, but that means that the > application has to still poll for it with PEER_ADDR_INFO. I think > the idea, as Thomas pointed out, is to easily see what the max rto > was. I like that, but I don't like the fact that it's per > association. With that stat we really don't know which transport > spiked. So, it gives us a some useful information, but not really > enough. > > It might be a little more useful to keep track of the which > transport has experienced the spike and then return info about it. > Granted, we may be too late and the spike corrected itself already, > but at least it will give the management application a little more > information and allow admin to have a little more info to determine > why the spike occurred. Agreed and good point, a per transport max rto makes more sense. -- 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
