>>> >>> So one potential way is to have peer.rwnd and peer.a_rwnd, where >>> peer.a_rwnd is >>> the window advertised by peer and peer.rwnd and our estimation based on >>> peer.a_rwnd. >>> This way we will always know where we stand. >>> >>> Although I am not sure yet if we want to grow the peer structure any more. >>> >>> Another way is to have an estimate or 0-window probe bit/flags one the send >>> side >>> and set it when we do 0-window probe. This way we'd know that when >>> 0-window probe >>> bit is set, peer returned 0 window. >>> >> I think updating 0-window may happen in sctp_process_init() and >> sctp_outq_sack(), >> I don't think 0-window can be probed, cause unreachable and closing >> window both has >> no reply from peer. but we can update the 0-window bit in those two >> functions. I just do >> not know where there is a available bit we can use if won't change the >> peer structure. > > You can ignore INIT as the window will never be 0 (not allowed). > > The updates could happen at the end of sctp_outq_sack(). There some spare > bits in peer if you want to go that way. > I find this one *addip_disabled_mask*, but it's really bad to use it. we should put a extensible mask or point there before.
as to a_rwnd, it's a good idea, but if we just use it here, it may not be worth doing that. if there are a lot places need it, we can add it. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
