Sporadic TCP/RST sent to client

[Julian Elischer]

On 28/6/17 2:31 am, Youssef GHORBAL wrote:
> [...]
>
>> Further, I would argue that round robin is not a valid 802.3ad/802.1AX
>> algorithm, per how it defines a frame distributor:
>>
>> "This standard does not mandate any particular distribution
>> algorithm(s); however, any distribution algorithm shall ensure that,
>> when frames are received by a Frame Collector as specified in 5.2.3,
>> the algorithm shall not cause:
>> a) Misordering of frames that are part of any given conversation, or
>> b) Duplication of frames.
>>
>> The above requirement to maintain frame ordering is met by ensuring
>> that all frames that compose a given conversation are transmitted on a
>> single link in the order that they are generated by the MAC Client;
>> hence, this requirement does not involve the addition (or
>> modification) of any information to the MAC frame, nor any buffering
>> or processing on the part of the corresponding Frame Collector in
>> order to reorder frames."
> I tend to agree with you on this point.
>
>>> Sure, I was just wondering if the FreeBSD network stack was built with the fact that each flow needs to arrive on the same NIC and the system was designed with this assumption in mind or not.
>>>
>>> I reported it here, thinking that maybe it's a subtle buggy corner case and maybe the community was interesting to know about and maybe fix :
>>>
>>> - If the stack is working as expected and was built with the assumption that each incoming flow needs to stick to a NIC during it's lifetime, maybe documentation needs to be more explicit regarding this situation. In that case I'll file documentation enhancement bug report.
>>> - If the stack is misbehaving, maybe help the community identify the root cause and help fixing it
>>>
>> As far as I can tell, as Navdeep noted, there's no unexpected
>> behaviour in your case. "Flows" are a concept that the protocols, in
>> this case TCP, knows about. The devices themselves (Ethernet cards)
>> usually have mechanics to make packet delivery decisions based on flow
>> information (e.g. RSS hashing), but as far as I know that is generally
>> limited within a single port, so it doesn't really help in the general
>> case of a lagg.
> So the fact that it works most of the time is just a "happy" coincidence. But it's not a behaviour to relay on. Right ?
>
> Anyway, thank you very much for your help and the clarification on this issue.

Basically, while the packets are "on the wire" anything could happen.

It would be theoretically possible for a lagg interface to do packet 
inspection and to not deliver (for some small amount of time) packets 
which showed sign of a missing earlier packet, but this is the job of 
other layers (e.g. tcp) and it would have negative impacts on 
performance of otherwise well behaved flows as well.
It would have to actually look at tcp headers and that is WAY out of 
scope for lagg. !t would also need a lot of state to be stored if it 
were to hold state for all recent sessions, and make the code MUCH 
more complicated.
Let tcp be tcp and push the linux owner to use something better.

>
> Youssef
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>