[{"author": "Jeffrey Haas", "text": "
I would like to wander over from lsr for the presentations on the yang modules. Could someone give 2 min warning before those presentations?
", "time": "2022-07-29T14:10:43Z"}, {"author": "Yoshifumi Nishida", "text": "ok. I will send message before the presentation
", "time": "2022-07-29T14:12:33Z"}, {"author": "Jeffrey Haas", "text": "Thank you.
", "time": "2022-07-29T14:13:01Z"}, {"author": "Neal Cardwell", "text": "Clarification: the \"issue 3\" is fixed in my draft patches, but not in Linux yet. The setting of alpha_cubic to 1 after cwnd > w_max or prior_cwnd is not in Linux yet.
", "time": "2022-07-29T14:19:33Z"}, {"author": "Rodney Grimes", "text": "Can you run Hystart++ with Cubic?
", "time": "2022-07-29T14:23:18Z"}, {"author": "Yi Huang", "text": "beta_cubic in windows TCP is 0.7 as well. JFYI.
", "time": "2022-07-29T14:23:25Z"}, {"author": "Jonathan Morton", "text": "@Rodney - I don't see why not
", "time": "2022-07-29T14:23:38Z"}, {"author": "Rodney Grimes", "text": "Does that solve the Alpha issue of issue 1?
", "time": "2022-07-29T14:23:56Z"}, {"author": "Jonathan Morton", "text": "it would be more related to issue 2 than 1
", "time": "2022-07-29T14:24:28Z"}, {"author": "Jonathan Morton", "text": "issue 1 is about the Reno compatibility mode
", "time": "2022-07-29T14:24:46Z"}, {"author": "Rodney Grimes", "text": "I miss typed, I meant issue 2
", "time": "2022-07-29T14:25:19Z"}, {"author": "Vidhi Goel", "text": "@Rodney, yes. And this is mentioned in the draft as well
", "time": "2022-07-29T14:27:28Z"}, {"author": "Rodney Grimes", "text": "If there are these issues perhaps instead of going to PS, why not take 8312bis to EXP, and get this data, then go to PS.
", "time": "2022-07-29T14:27:57Z"}, {"author": "Jonathan Morton", "text": "Issue 1: the current value of C in CUBIC_alpha is widely deployed and isn't causing any obvious problems, so I don't see the need to change it for a theoretical reason
", "time": "2022-07-29T14:29:59Z"}, {"author": "Jonathan Morton", "text": "Issue 2: likewise 0.7 is widely deployed and isn't causing any practical problems, since in a deep buffer HyStart is likely to trigger before the buffer is full
", "time": "2022-07-29T14:30:45Z"}, {"author": "Jonathan Morton", "text": "while a shallow buffer is likely to be associated with AQM which likely triggers before the buffer is full
", "time": "2022-07-29T14:31:20Z"}, {"author": "Rodney Grimes", "text": "@Jonathan, so that would explain WHY we dont see an issue with the 0.7, and in effect that value just wont matter due to HyStart kicking in?
", "time": "2022-07-29T14:31:40Z"}, {"author": "Jonathan Morton", "text": "correct
", "time": "2022-07-29T14:31:52Z"}, {"author": "Jonathan Morton", "text": "so CUBIC_beta should be tuned for congestion avoidance mode rather than slow-start exit
", "time": "2022-07-29T14:32:18Z"}, {"author": "Rodney Grimes", "text": "So the problem is \"Hidden\". sigh
", "time": "2022-07-29T14:33:06Z"}, {"author": "Jonathan Morton", "text": "remind me to discuss this with you elsewhere
", "time": "2022-07-29T14:35:14Z"}, {"author": "Neal Cardwell", "text": "Thanks for the clarification Bob. Can you please point to the slide numbers in your ICCRG slides that have Reno and CUBIC in the same queue? Thanks!
", "time": "2022-07-29T14:41:26Z"}, {"author": "Neal Cardwell", "text": "AFAICT those are all with an AQM, and I think Markku's concern with alpha mainly pertained to CUBIC and Reno coexisting in that drop-tail FIFO.
", "time": "2022-07-29T14:42:35Z"}, {"author": "Neal Cardwell", "text": "Note in Markku's email https://mailarchive.ietf.org/arch/msg/tcpm/pN1fARPVzqcDlt--xiMoDm_loAM/ the phrase: \" he model is incorrect for the traditional and still today prevailing tail-drop router case\"
", "time": "2022-07-29T14:45:33Z"}, {"author": "Vidhi Goel", "text": "I believe its slide 8 in Bob's slides in ICCRG.
", "time": "2022-07-29T14:47:43Z"}, {"author": "Neal Cardwell", "text": "If I'm reading that correctly, that's showing \"ECN-CUBIC\" vs Reno, which again sounds like an AQM (to get the ECN marking) rather than drop-tail.
", "time": "2022-07-29T14:54:04Z"}, {"author": "Gorry Fairhurst", "text": "I left the queue
", "time": "2022-07-29T14:55:40Z"}, {"author": "Vidhi Goel", "text": "there is ECN-CUBIC and then there is just CUBIC. I am not sure if just CUBIC uses any AQM
", "time": "2022-07-29T14:55:54Z"}, {"author": "Jonathan Morton", "text": "I don't think any of the graphs shown in the Prague CC material involve a drop-tail bottleneck
", "time": "2022-07-29T14:56:48Z"}, {"author": "Neal Cardwell", "text": "The \"Reno\" in slide 8 is only on the second row, which only has \"ECN-CUBIC\" results, not \"CUBIC\" results.
", "time": "2022-07-29T14:57:50Z"}, {"author": "Neal Cardwell", "text": "My sense agrees with Jonathan's, that none of the graphs shown in the Prague CC material involve a drop-tail bottleneck.
", "time": "2022-07-29T14:58:15Z"}, {"author": "Gorry Fairhurst", "text": "ACK filtering change worked for me, thanks.
", "time": "2022-07-29T14:59:47Z"}, {"author": "Yoshifumi Nishida", "text": "accn presentation is toward the end
", "time": "2022-07-29T15:01:05Z"}, {"author": "Yoshifumi Nishida", "text": "next wiil be yang
", "time": "2022-07-29T15:01:46Z"}, {"author": "Neal Cardwell", "text": "Clarification, this Linux code we tested this week was Ilpo's AccECN code.
", "time": "2022-07-29T15:05:07Z"}, {"author": "Chris Box", "text": "Yang presentation is starting
", "time": "2022-07-29T15:19:06Z"}, {"author": "Lars Eggert", "text": "keepalives?
", "time": "2022-07-29T15:35:08Z"}, {"author": "Rodney Grimes", "text": "Keepalive and dead timer should tear down the BGP sessession.
", "time": "2022-07-29T15:35:58Z"}, {"author": "Michael T\u00fcxen", "text": "Application layer keep alives / heartbeat
", "time": "2022-07-29T15:35:58Z"}, {"author": "Wesley Eddy", "text": "or ... more YANG
", "time": "2022-07-29T15:36:08Z"}, {"author": "Rodney Grimes", "text": "This \"case #1\" was solved over 30 years ago.
", "time": "2022-07-29T15:36:44Z"}, {"author": "Lars Eggert", "text": "i don't understand why a broken application needs to be fixed by having another application look at arbitrary TCP state
", "time": "2022-07-29T15:42:13Z"}, {"author": "Jeffrey Haas", "text": "@Lars Eggert The application itself is often not broken. It's broken TCP and the application is the victim.
", "time": "2022-07-29T15:51:02Z"}, {"author": "Jeffrey Haas", "text": "And while we have the headaches that come on occasion from modifying tcp stacks, we also have similar issues with bugs in stock Linux stacks.
", "time": "2022-07-29T15:52:01Z"}, {"author": "Jeffrey Haas", "text": "You develop a different perspective on the bugs when your tcp sessions are often up for months.
", "time": "2022-07-29T15:52:15Z"}, {"author": "Jonathan Morton", "text": "in the case mentioned, the application was hung but the TCP stack was still operating
", "time": "2022-07-29T15:52:17Z"}, {"author": "Jeffrey Haas", "text": "Understood that was the example. I'm offering another example.
", "time": "2022-07-29T15:52:35Z"}, {"author": "Jeffrey Haas", "text": "The hung state from a wedged receiver has a discussion for a \"send holdtimer\" to cover this condition in the IDR mailing list.
", "time": "2022-07-29T15:54:01Z"}, {"author": "Gorry Fairhurst", "text": "Why do we need R so large? .. just because it is possible???? .. ona 1 Gbps link, we can have 1 ACK every 100 or so packets, with little overhead=
", "time": "2022-07-29T15:54:39Z"}, {"author": "Gorry Fairhurst", "text": "In another case: A large value is harmful also when there is path flapping or a path change.
", "time": "2022-07-29T16:01:57Z"}, {"author": "Neal Cardwell", "text": "80Gbps * 100ms is a BDP of 660,502 packets, at MTU=1500bytes. In which case an ACK per 2,000 packets would give 330 ACKs per round trip. So IMHO a max value of 2047 is reasonable.
", "time": "2022-07-29T16:01:57Z"}, {"author": "Gorry Fairhurst", "text": "Is it reasonable from a CC perspective?
", "time": "2022-07-29T16:02:28Z"}, {"author": "Jonathan Morton", "text": "yes, this was the thrust of the mathematics I posted on the list
", "time": "2022-07-29T16:02:29Z"}, {"author": "Neal Cardwell", "text": "Yes, it's reasonable from a CC perspective if the CC is using pacing, which it ought to be.
", "time": "2022-07-29T16:02:51Z"}, {"author": "Neal Cardwell", "text": "As Jonathan noted, if there is loss, the receiver will ACK immediately.
", "time": "2022-07-29T16:03:05Z"}, {"author": "Jonathan Morton", "text": "if congestion feedback is generated by the receiver or on the path, this will result in immediate acks regardless of the value of R
", "time": "2022-07-29T16:03:07Z"}]