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

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

My understanding of TCP zero window is different.
It is the peer sending 0 in the "window" field of the TCP header
in the 16 bit word, at offset 14 bytes into the header.
That means it will not accept any TCP data from you,
but it is perfectly capable of sending you data and
accepting your acks for it.
If it were not so, then it would not be able to send you keepalives
and your hold timer would expire.

If a peer sends you zero window, it means one thing only:
That it does not have your latest routes.

It does not mean that all its other routes are also stale.
If that were the case, then it would send zero window to its
other peers and they would take care of it themselves.

It does not mean that the data plane is broken.
If that were the case, you would get either no keepalives
from the peer or no more acks to your own keepalives.

If forwarding is broken one way from you to your peer, then
you will no longer get ACKs back from keepalives or other
BGP packets you send to your peer. This is not a zero window
condition. This may be another condition we wish to monitor.
Note, there are other ways to monitor this condition, e.g. BFD.

Regards,
Jakob.

-----Original Message-----
From: Jeffrey Haas <[e-mail]> 
Sent: Sunday, April 25, 2021 12:27 PM
To: Jakob Heitz (jheitz) <[e-mail]>
Cc: Robert Raszuk <[e-mail]>; idr@ietf. org <[e-mail]>; Ben Cox <ben=[e-mail]>
Subject: Re: [Idr] draft-spaghetti-idr-bgp-sendholdtimer - Feedback requested

Jakob,

On Sun, Apr 25, 2021 at 06:01:06AM +0000, Jakob Heitz (jheitz) wrote:
> A long time of TCP zero window does not indicate a data plane
> problem, nor a problem with routes received from the stuck peer.
> The blockage is in one direction only. The local speaker is unable
> to end routes to the stuck peer, but is able to receive routes
> from the stuck peer just fine.

This tickles a related point:

If a peer has zero-windowed you, you are unable to send any ACK
frames to that peer.  This means that we're potentially in a very slow race
for the remote peer to eventually send enough data that it similarly zero-
windows.

At that point, the remote peer should eventually give up trying to transmit
as well. Locally, the hold timer would expire.

> Therefore, I would propose that the response of the local speaker
> should be to retain the routes of the stuck peer when it resets the
> session, GR style.

Having GR is a reasonable mitigation when you're not concerned about the
routes the local router having already been stuck for a very long time.

In some circumstances it may make better sense to get the router with the
misbehaving TCP session out of the forwarding path as possible.

-- Jeff