Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

From: Enke Chen <[email-masked]>
Date: Fri, 11 Dec 2020 22:15:08 -0800

Hi, Folks:

There is an interesting article titled "When TCP Sockets Refuse to Die":

      https://blog.cloudflare.com/when-tcp-sockets-refuse-to-die/

which recommends using the TCP keepalive option and the TCP_USER_TIMEOUT
option together to deal with several TCP "stuck" scenarios.

To strike a balance between maintaining routing stability and working
around these corner cases, how about we recommend using these two TCP
options with a timeout value larger than the BGP per-session holdtimer
(e.g.,  2 * bgp_holdtimer) ?

Thanks.   -- Enke
------
Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired,
because TCP recv window is 0

"Jakob Heitz (jheitz)" <[email-masked]> Sat, 12 December 2020 03:29 UTCShow
header <https://mailarchive.ietf.org/arch/browse/idr/#>

Good point Keyur.

A receiver may be overwhelmed for a long time and not open its TCP
window to avoid
silly window syndrome or some other reason. The receiver may still be functional
and able to clear its backlog, albeit in a long time. Resetting such a session
will only make the situation worse. Telling the difference between this case
and a receiver stuck in a bug is difficult.

Regards,
Jakob.

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Sat, 12 Dec 2020 07:15:24 +0000

Kill and restart all from scratch with BGP is a scary prospect,
especially if it's just going to repeat.

How about we graceful restart it.
Require GR to be in effect on the session.
Then either RST or silently drop the session and start a new one.
The receiver should accept the new session and do GR.
And, yeah, use a long timer. Don't restart again until at least the EOR
is both sent and received and only then start the boom timer again.

Regards,
Jakob.

From: Idr <[email-masked]> On Behalf Of Enke Chen
Sent: Friday, December 11, 2020 10:15 PM
To: [email-masked]
Cc: Enke Chen <[email-masked]>
Subject: Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

Hi, Folks:

which recommends using the TCP keepalive option and the TCP_USER_TIMEOUT option together to deal with several TCP "stuck" scenarios.

To strike a balance between maintaining routing stability and working around these corner cases, how about we recommend using these two TCP options with a timeout value larger than the BGP per-session holdtimer (e.g.,  2 * bgp_holdtimer) ?

Thanks.   -- Enke
------
Re: [Idr] TCP & BGP: Some don't send terminate BGP when holdtimer expired, because TCP recv window is 0

"Jakob Heitz (jheitz)" <[email-masked]<mailto:[email-masked]>> Sat, 12 December 2020 03:29 UTCShow header<https://mailarchive.ietf.org/arch/browse/idr/>

Good point Keyur.

A receiver may be overwhelmed for a long time and not open its TCP window to avoid

Regards,

Jakob.

---

From: Enke Chen <[email-masked]>
Date: Sat, 12 Dec 2020 10:52:00 -0800

Hi, Jakob:

It's about recovery from corner cases that occur rarely than other
"holdtime expiration" events.

Keep it simple and robust.

Thanks.   -- Enke

On Fri, Dec 11, 2020 at 11:15 PM Jakob Heitz (jheitz) <[email-masked]>
wrote:

> *From:* Idr <[email-masked]> *On Behalf Of * Enke Chen
> *Sent:* Friday, December 11, 2020 10:15 PM
> *To:* [email-masked]
> *Cc:* Enke Chen <[email-masked]>
> *Subject:* Re: [Idr] TCP & BGP: Some don't send terminate BGP when
> holdtimer expired, because TCP recv window is 0
>
>
> Hi, Folks:
>
>
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__blog.cloudflare.com_when-2Dtcp-2Dsockets-2Drefuse-2Dto-2Ddie_&d=DwMGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=lifWUvp3-DcEhCcrTN7S0OaBssKd2YgRWJK9wKS6kME&s=iaULKaznGYFPvvgj5LqIC6FRCjyl4DU6NzlDLBRNoKA&e=>
>
>
>
> header
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_idr_&d=DwMGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=OPLTTSu-451-QhDoSINhI2xYdwiMmfF5A2l8luvN11E&m=lifWUvp3-DcEhCcrTN7S0OaBssKd2YgRWJK9wKS6kME&s=VXdBMh8C3fKDigTD71jkq9slGVhCFKdLa5EqbvlCUbg&e=>
>
> Good point Keyur.
>

---

From: Jared Mauch <[email-masked]>
Date: Sat, 12 Dec 2020 14:03:48 -0500

> On Dec 12, 2020, at 1:52 PM, Enke Chen <[email-masked]> wrote:
> 
> Hi, Jakob:
> 
> It's about recovery from corner cases that occur rarely than other "holdtime expiration" events.
> 

If a vendor ships an unsafe transport protocol, it’s going to have all these bad behaviors.

I’m wondering how bad this is for non-XR people vs XR people where it’s a known issue.

- Jared