On Tue, Dec 06, 2005 at 06:29:04AM +1100, Darren Reed wrote: > > What appears to happen is a hole develops at one end, at the > start of the window, the receiver understands this, the missing > piece gets sent, followed by what's to the right of the window. > > The right edge of the window has been updated only by the SACK > option, which IPFilter doesn't see and so IPFilter doesn't > match up with the packet. > > So we have: > > left_edge = A > valid = [A,A+window) > > the receiver sends back ACKs for A plus SACK of [A+MSS,A+MSS*2) > (as an example) to the point of [A+window-MSS,A+window). > So IPFilter has only seen an ACK for A but the sender has seen > ACKs for everything but "hole" courtesy of SACK. > > hole = [A,A+MSS) > > So the sender now sends [A,A+MSS) followed by [A+window,A+window+MSS). > Of course the sender might follow the hole filler with > [A+window,A+window*2) of data. >
I don't think that is valid. The windows is not just an amount of data, but a point relative to the last ACK. The windows only opens up when the application on the receiver has actually digested the data. So in my view, the sender should indeed send [A,A+MSS) but the window is closed (all data [A,A+window) has been sent). It should wait for a new ack of A+window AND a window advertisement. It might well be that the application on the sender is somehow stalled and has not read the data back in. That means that the TCP stack cannot but hold the complete window of data in the kernel and advertise a zero window to the sender. -Guido
