lwip-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Joel Cunningham
Subject: Re: [lwip-devel] [bug #50837] TCP: zero window probe doesn't timeout
Date: Tue, 27 Jun 2017 21:49:09 +0000 (GMT)

On Jun 27, 2017, at 01:52 PM, "address@hidden" <address@hidden> wrote:

Joel Cunningham wrote:
Follow-up Comment #38, bug #50837 (project lwip):

I agree that treating the send window as effectively zero when the next unsent
segment is larger, is becoming more messy to maintain.

Slightly off-topic so continuing on the list:
In the case of "0 < wnd < pcb->unsent->len" (next segment does not fit
into the window), until now we discussed 2 options:
- handle this case the same as a true zero window
- split segments and send what fits into the window

What about just sending the full segment in this case? The receiver
might or might not ACK the full segment, but
shouldn't that just work?

There was some discussion of that in the original bug adding the Persist Timer:

https://savannah.nongnu.org/bugs/?func=detailitem&item_id=20511#comment6

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.

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.

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.

Joel

reply via email to

[Prev in Thread] Current Thread [Next in Thread]