š
Original date posted:2019-01-02
š Original message:
On Wed, 2 Jan 2019 at 18:26, Christian Decker
<decker.christian at gmail.com> wrote:
>
> For the ones that flap with a period that is long enough for the
> disabling and enabling updates being flushed, we are presented with a
> tradeoff. IIRC we (c-lightning) currently hold back disabling
> `channel_update`s until someone actually attempts to use the channel at
> which point we fail the HTLC and send out the stashed `channel_update`
> thus reducing the publicly visible flapping. For the enabling we can't
> do that, but we could think about a local policy on how much to delay a
> `channel_update` depending on the past stability of that peer. Again
> this is local policy and doesn't warrant a spec change.
>
> I think we should probably try out some policies related to when to send
> `channel_update`s and how to hide redundant updates, and then we can see
> which ones work best :-)
>
Yes, I haven't looked at how to handle this with local policies. My
hypothesis is that when you're syncing a routing table that is say one
day old, you end up querying and downloading a lot of information that
you already have, and that adding a basic checksum to our channel
queries may greatly improve this. Of course this would be much more
actionable with stats and hard numbers which I'll provide ASAP.
Cheers,
Fabrice
Fabrice Drouin [ARCHIVE] /
npub1s8ā¦5yaw4
2023-06-09 12:53:50
in reply to nevent1qā¦9exx
Author Public Key
npub1s8zghfrvyydu3ld5jrgue7crvzw8agyslpv8mh9pexgxwmcfelfsk5yaw4Published at
2023-06-09 12:53:50Event JSON
{
"id": "19cedde4ce27ce2c9638cc4926e56023d61d0d6d6940c696ae28e304c76f3be7",
"pubkey": "81c48ba46c211bc8fdb490d1ccfb03609c7ea090f8587ddca1c990676f09cfd3",
"created_at": 1686315230,
"kind": 1,
"tags": [
[
"e",
"fd0da5dbd5383b525edc98216d5094b180c1b831bf7af1f8df8ca35294a8c8fd",
"",
"root"
],
[
"e",
"a022c9f78c34c21088cd49fe45c41ba2e69689a959a5871748362e9a5c4745a5",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "š
Original date posted:2019-01-02\nš Original message:\nOn Wed, 2 Jan 2019 at 18:26, Christian Decker\n\u003cdecker.christian at gmail.com\u003e wrote:\n\u003e\n\u003e For the ones that flap with a period that is long enough for the\n\u003e disabling and enabling updates being flushed, we are presented with a\n\u003e tradeoff. IIRC we (c-lightning) currently hold back disabling\n\u003e `channel_update`s until someone actually attempts to use the channel at\n\u003e which point we fail the HTLC and send out the stashed `channel_update`\n\u003e thus reducing the publicly visible flapping. For the enabling we can't\n\u003e do that, but we could think about a local policy on how much to delay a\n\u003e `channel_update` depending on the past stability of that peer. Again\n\u003e this is local policy and doesn't warrant a spec change.\n\u003e\n\u003e I think we should probably try out some policies related to when to send\n\u003e `channel_update`s and how to hide redundant updates, and then we can see\n\u003e which ones work best :-)\n\u003e\nYes, I haven't looked at how to handle this with local policies. My\nhypothesis is that when you're syncing a routing table that is say one\nday old, you end up querying and downloading a lot of information that\nyou already have, and that adding a basic checksum to our channel\nqueries may greatly improve this. Of course this would be much more\nactionable with stats and hard numbers which I'll provide ASAP.\n\nCheers,\n\nFabrice",
"sig": "d60bfac28cf5f692c5e0cd464e5f5e51682d68d294750530b00e8f74fd5a733d1d073731a2230ccd62db139bf593170d54f3cb24347d1ce982a4933c7d082a83"
}