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: address@hidden
Subject: Re: [lwip-devel] [bug #50837] TCP: zero window probe doesn't timeout
Date: Thu, 29 Jun 2017 20:14:15 +0200
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

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...


Simon



reply via email to

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