Bug 2018930
| Summary: | [OCP 4.8][OVN] packet delay in communication between Pods | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Aaron Park <aapark> |
| Component: | Networking | Assignee: | mcambria <mcambria> |
| Networking sub component: | ovn-kubernetes | QA Contact: | Anurag saxena <anusaxen> |
| Status: | CLOSED CURRENTRELEASE | Docs Contact: | |
| Severity: | urgent | ||
| Priority: | urgent | CC: | aconole, akaiser, bpickard, bzvonar, cgoncalves, cverna, dcbw, ealcaniz, fleitner, fpaoline, jajeon, jcaamano, jinjli, jmaxwell, jseunghw, mcambria, mleitner, mwasher, nusiddiq, openshift-bugs-escalate, pweil, tidawson, vlaad, zzhao |
| Version: | 4.8 | Keywords: | TestCannotAutomate |
| Target Milestone: | --- | Flags: | bpickard:
needinfo-
bpickard: needinfo- mcambria: needinfo? mcambria: needinfo? |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-10-31 16:50:32 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 2074566 | ||
| Bug Blocks: | |||
|
Description
Aaron Park
2021-11-01 09:57:09 UTC
On a worker node, could you grab the output of: iptables-save ovs-ofctl dump-flows br-ex (In reply to Dan Williams from comment #1) > On a worker node, could you grab the output of: > > iptables-save > ovs-ofctl dump-flows br-ex Nevermind, I see they are contained in the sosreport attached to the customer case. Is the pcap attached to comments 68 and 69 the same as the existing and provided pcap? *** Bug 2054102 has been marked as a duplicate of this bug. *** If there is still a delay of 200ms with the kernel that has the backport [1], it should be easy to produce pcaps which support this The backport of this fix is supposed to fix the 200ms delay (make the re-xmit faster, not 200ms later.) If the kernel isn't re-transmitting packets due to ~100 duplicate acks being received with [1] this still has to be fixed in Linux. [1] https://github.com/torvalds/linux/commit/a29cb6914681a55667436a9eb7a42e28da8cf387 (In reply to mcambria from comment #103) > > If there is still a delay of 200ms with the kernel that has the backport > [1], it should be easy to produce pcaps which support this > > The backport of this fix is supposed to fix the 200ms delay (make the > re-xmit faster, not 200ms later.) > There are still some instances of the 200ms retransmissions in the pcaps with the patched kernel containing: net: tcp better handling of reordering then loss cases There are some of varying times like 39ms where RACK calculated the optimal RTO interval based on heuristics as well. There are some regular retransmissions that had an interval of few ms and recovered very fast. > If the kernel isn't re-transmitting packets due to ~100 duplicate acks being > received with [1] this still has to be fixed in Linux. > > > [1] > https://github.com/torvalds/linux/commit/ > a29cb6914681a55667436a9eb7a42e28da8cf387 I was reading the RACK RFCs and looking at the code that Yuchung implemented. It's a lot more complex than the older pre-RACK tcp dupack recovery mechinism. AFAICT it's supposed to be a lot smarter than the basic 3 dupacks will trigger a fast retransmission. I don't think RACK will guarantee that there will never be 200ms timer based retransmissions. The commit improved some situations but there are other valid reasons that 200ms restransmit can occur. |