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: Thu, 29 Jun 2017 20:04:51 +0000 (GMT)



On Jun 29, 2017, at 01:14 PM, "address@hidden" <address@hidden> wrote:

Joel Cunningham wrote:
The idea of performing the split upon the first fire of the persist
timer seems a reasonable compromise

The downside is that for this to work, we'd have to start the persist
timer before receiving a zero window. Which is what we do now already
but which is a bit off the standard. Sending a split segment then seems
to me like only solving cases where otherwise the connection would get
stuck. You see I tend to shift positions here, but as arguments come to
mind...

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 muc

That was my initial thought, exactly.

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?

I guess it's copying the data. You could argue that we could just
reference the remainder (much like the ip-frag code does) and wouldn't
have to copy, but then most zero-copy MACs have to memcpy anyway due to
bad alignment (I assume most DMAs nowadays have at least a 4-byte
alignment requirement so statistically, a 3:1 chance that such a
scatter-gather MAC has to memcpy).

This is all feeling however. I don't have numbers of what exactly this
would mean.

Given all this, I still think our current approach is the best. Splittin
segments when the persist timer expires would only mean more code.
Unless the complete window is < 4*MSS, I don't expect problems here...

By current approach, you mean continue with the early-zero-window behavior and implement the check suggested in comment #34/35?

https://savannah.nongnu.org/bugs/?50837#comment34

I agree that none of the alternatives seem much simpler, though figuring out how to do the segment split in a performant manner would be nice
Joel

reply via email to

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