[{"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"}]