Re: [Idr] WG Adoption call for draft-spaghetti-idr-bgp-sendholdtimer-09 (2/28/2023 to 3/14/2023)

[Jeffrey Haas <[e-mail]>]

> On Mar 8, 2023, at 12:06 PM, Mikael Abrahamsson <[e-mail]> wrote:
> 
> On Wed, 8 Mar 2023, Jeffrey Haas wrote:
> 
>> In one case, it's not necessary for a sender to block due to lack of buffer.  TCP can provide the necessary information via user-timeout that the receiver is not consuming the things sent to it.  This is the user-timeout methodology.
> 
> This is not how I read RFC5482 (which I hope is the one we're discussing).
> 
> That's why I don't understand how user-timeout solves anything we're discussing here. User-timeout seems to just solve issues on the wire, not application layer.

You're correct about this.

The headache at hand is missing acks and signaling a half duplex disconnect compared to acks getting through but the window not opening.  That's your point, yes?


> 
>> Both approaches will eventually tell you that a receiver isn't draining.
> 
> Does it? If the receiver is not reading the socket, window goes to 0 and there's no data to be left un-acknowledged as it hasn't been sent yet, so I don't see how user-timeout will help.

Mostly the scenario where you get sender backpressure because of lost acks.

If this isn't the scenario you're primarily concerned about, then I agree that it seems like a distraction.

The headache I've lived with over the years is that from the perspective of a socket programmer, you don't get insight as to what is causing blockage.  Is it because acks aren't getting through with information that opens the window?  Is it that acks get through and the window isn't opening and stays zero-windowed for a long time?  

At the API layer, you just know that you're blocked.

Once you're to the point of starting tcpdump to figure out *why* you're blocked, you're already in trouble.

For the lost ack case, the timeout is helpful in helping you determine that tcp simply won't be able to help you.  This can permit you to bail out faster than waiting on default tcp timer behaviors.  

Does that solve the entirety of this problem?  No.  And that no is why I'm not presenting the timeout as "this is THE SOLUTION to the problem".  At best, it's a useful tool in helping out.  Even then, I'm uncomfortable with what an appropriate timeout would need to be.

> There is running code for the sendholdtimer proposal that has been shown to help, can the people proposing user-timeout please provide code and test-case to show that it actually works the way they think?

That would indeed be helpful.

-- Jeff