Re: [lwip-devel] [bug #50837] TCP: zero window probe doesn't timeout

[Joel Cunningham]

> On Jun 28, 2017, at 14:34, "address@hidden" <address@hidden> wrote:
> 
> Joel Cunningham wrote:
>> There was some discussion of that in the original bug adding the Persist 
>> Timer:
> 
> Thanks for the reminder. I had the thought of this being talked about 
> somewhere...
> 
>> It looks like there was hesitation about whether the remote TCP could handle 
>> this even though Steven's says the receiver should trim the segment to what 
>> will fit.
> 
> By now I'd say we should just try it. There are three possibilites: the 
> segment will not be ACKed, the segment will be partially ACKed or the segment 
> wil be fully ACKed. Of course, we would have to be prepared for all those.
> 
>> 
>> If LwIP was modified to behave this way, it wouldn't be able to remove the 
>> segment from the unacked queue when receiving the zero window update because 
>> we only support receiving an ACK covering the full segment.  Maybe this 
>> would be ok since in tcp_slowtmr(), the persist timer effectively overrides 
>> the RTO timer when active and we wouldn't retransmit during the zero window.
> 
> Hmm, that would only work if the remote host ACKed the data inside the window 
> - not more and not less.
> 

Good point on the ACKing less. If that happened, we'd have the same behavior as 
now since the window would not be full, but also with a segment on the unacked 
queue

>> Also, calculations for determining the in-flight data would show an amount 
>> exceeding the receiver's advertised window, not sure if that will cause any 
>> problems, needs more investigation.
> 
> That's also true. Given all that, this solution probably is the same mess as 
> our current behaviour of "early-zero-window". Any preference?
> 
Agreed that sending the entire packet seems to be as complicated as the 
"early-zero-window" behavior we have now. The idea of performing the split upon 
the first fire of the persist timer seems a reasonable compromise to performing 
the split upon every fill of the window. I would imagine most of the time, the 
receiver would have a window update before the timer fires, so the split 
doesn't end up happening much

The split I had implemented allocated a new pbuf for the remainder + new TCP 
header, then trimmed the original. What level of optimization would it take to 
be ok always doing the split? Is it copying the remainder payload that's the 
problem or more generally just doing re-segmentation?

Joel