On 3/04/2012 11:45 PM, Andre Oppermann wrote: > On 01.04.2012 09:27, Darren Reed wrote: >> Andre, >> >> Your changes bring it closer to working correctly with a >> small change: rather than "tiwin > tp->snd_wnd", it should >> be "tiwin != tp->snd_wnd". In this trace, the remote end >> has set a window scale factor of 5 during connection >> establishment. >> >> The same change should be made in the if() a few lines down. > > Window updates are a tricky thing by that we must not accept > old and outdated segments to update our window. Hence we have > to test for freshness while at the same time be open enough > to handle weird cases like bidirectional data transfers on > lossy links with data waiting in reassembly queues on both > sides. > > There are two clear cut cases we can accept a window update: > > a) the incoming segment ACK'ed new data (moved snd_una). > b) the incoming segment carries new data (moved rcv_nxt). > > The latter gets tricky already with the addition of the > reassembly queue. Here only segments that have a higher SEQ > than highest already present in the reassembly queue are OK. > > And then we have a window probe where we'll get an answer > that neither moves our ACK (zero byte probes) nor carries > any data. Here the window update is vital for the future > progress of the session.
Hmmm, what about retransmitted data that fills a response in response to a TCP packet with SACK present? So that would be (b) from above but rcv_nxt does not get moved? So remote sends 4 packets with 1440 data bytes, freebsd82 receives pkts 1, 3 & 4, ACK's 1, uses SACK to repsond to 3 & 4, new data arrives from remote at freebsd82 but with the TCP window set to 0. >> The problem here is that it only tracks the window size as >> it grows, not as it shrinks. Thus the remote end setting its >> window size to 0 is ignored. > > My patch is wrong as the acked count is already integrated > by the time we reach this spot. I'm working on a better > implementation. Ok, I'll look forward to seeing and testing it. > It's the other way around. remote.ssh is sending old data > which freebsd82.62922 has already ack'ed. The sessions seems > to be de-synchronized, perhaps some middle box mucking with > the segments trying to modulate something? I suspect that the ISP is dropping packets and/or applying some other means of throttling the connection. So, yes. Darren _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
