Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

["Jakob Heitz (jheitz)" <[e-mail]>]

Phenomena that cause keepalives (or any packets) to be delayed are
different to phenomena that cause zero window.
Network delays caused by buffering in intermediate switches as well
as at the TCP endpoints will delay keepalives and will also delay the
clearing of a zero window condition.
There are a myriad of other phenomena that can cause zero window
to persist that are not network related.
Ideally, even a slow receiver should be punctuating periods of zero
window with short periods of non-zero window as it moves its
in-queue. However, that's not a requirement. An implementation
that takes a big gulp and then lies down to chew its cud for 10
minutes is not breaking any rules. I don't know of any such
implementations, but I've not seen them all.

I prefer the medicine to be safe before effective, so I will advocate
for a long default timer.

Regards,
Jakob.

From: Enke Chen <[e-mail]>
Sent: Friday, April 23, 2021 11:54 AM
To: Brian Dickson <[e-mail]>
Cc: Job Snijders <[e-mail]>; Jakob Heitz (jheitz) <[e-mail]>; Ben Cox <[e-mail]>; [e-mail]
Subject: Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

Hi, Brian:

Isn't the holdtimer already per-neighbor based?

Regards,  -- Enke

On Fri, Apr 23, 2021 at 11:51 AM Brian Dickson <[e-mail]<mailto:[e-mail]>> wrote:


On Fri, Apr 23, 2021 at 10:31 AM Enke Chen <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Folks:

The holdtimer already conveys whether the session should be timed out sooner or later. It makes sense to tie the new timer with it, perhaps with a configurable multiplier. The default could be 1, or 2.


This is a bad idea (having the only "knob" be a multiplier).

It might be okay for the default to be derived from some multiplier over the default for holdtimer, but it is not okay for the knob to be ONLY a multiplier.

Here's why:

A router with a large number of BGP sessions, where those sessions have different characteristics, such as RTT, loss, bandwidth, etc., are very likely to behave quite differently.
(There are any number of operational reasons a router might have connections of this sort, it's really not worth detailing all the reasons, but some examples would include a router with both local LAN peers (customers) and satellite peers; peering extension providers over multi-city links; underprovisioned peer routers; software router peers, etc.)

The operator should (MUST) have exposed controls to adjust timers on a per-neighbor basis, and/or per-router basis (when managing large numbers of routers).

The purpose of this proposal is not met if that level of granularity is unavailable.

The operator has the ability to understand why individual peering sessions may be behaving this way, and will need to adjust the parameters on a per-peer basis.
Fixing a problem for one peer, should not introduce problems for another peer.

This isn't 1995.

Respectfully,
Brian

Thanks.   -- Enke

On Fri, Apr 23, 2021 at 5:43 AM Job Snijders <job=[e-mail]<mailto:[e-mail]>> wrote:
Hi Jakob, group,

Thanks for the feedback, a -02 has been submitted.

On Fri, Apr 23, 2021 at 12:56:40AM +0000, Jakob Heitz (jheitz) wrote:
> I propose to add this text:
>
> It is possible that a BGP speaker presents a TCP zero receive window
> after receiving a large batch of updates. Resetting the session to
> such a speaker may just repeat the large batch, whereas waiting a little
> longer may have given it a chance to recover. The possibility of this
> occurrence makes it difficult to determine a good value for the
> timer. The default value of the timer is therefore recommended
> to be 15 minutes.

In this email John Scudder appears to suggest using a separate new
timer, and populate the timer with the default HoldTimer value (and the
-02 draft attempts to describe exactly that).
https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_idr_E5pqxIObPS7e9A2IqIApTHVSfig_&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=ic9GqvTL_AVNp--whyEU4xnDPEpswdHPBNt_XoBG99g&e=

you propose 15 minutes; so it seems there is some convergent thinking in
the group the proposed timers at hand is in the order of 'multiple
minutes'.

How long should a BGP speaker be willing to buffer on behalf of another
BGP speaker's inability to progress message processing?

If the oldest message in the queue is a KEEPALIVE message, and its been
stuck there for more than HoldTimer, wouldn't we have expected the
remote side to have killed the BGP session anyway?

Would you mind sharing your thinking on why a default of 15 minutes is
better than for example 180 seconds? What do others think?

Kind regards,

Job

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwICAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=bQFpOg20Jvvi5Fdn0FbsPn3umJ_yRN4nNcXfCsfl5ek&s=PHKZKmQoCjqpWGGBhDIpOnAaSlDjeRsLdEPlOwChzyw&e=
_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_idr&d=DwMFaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=ecQzdLStIaoAFzguVP-QtyJpUCwi8K4lXMCt2ey-mZE&s=GquAlygyileCKhzvo6AEjoKhUu6R2Z3sSmft31rxH9s&e=>