Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

From: Christian Hopps <[email-masked]>
Date: Tue, 10 Mar 2020 10:48:05 -0400

Les Ginsberg (ginsberg) <[email-masked]> writes:

> Tony –
>
> If you have a suggestion for Tx back-off algorithm please feel free to share.
> The proposal in the draft is just a suggestion.
> As this is a local matter there is no interoperability issue, but certainly documenting a better algorithm is worthwhile.

[as WG member]

The main thing I'm afraid of is we're just making up some new overly simple congestion control algorithm (are there CC experts reviewing this?); maybe simulate it a few ways, deploy it, and have it work poorly or make things worse. In any case, damn the torpedos...

In this current algorithm how does MaxLSPTx get set? What happens if MaxLSPTx is too high? If its too low we could be missing a much faster convergence capability.

What if we had more quality information from the receiver, could we do a better job here? Maybe faster ACKs, or could we include a timestamp somehow to calculate RTT? This is the type of data that is used by existing CC algorithms (https://tools.ietf.org/html/rfc4342, https://tools.ietf.org/html/rfc5348). Of course going through these documents (which I've had to do for in another area) can start making one think "Punt to TCP" :)

What would be nice, if we're going to attempt CC, is that the algorithm would be good enough to send relatively fast to start, adjust quickly if need be, and allow for *increasing* the send rate. The increasing part I think is important, if we take this work on, and I don't think it's currently covered.

I also don't have a good feel for how quickly the current suggested algorithm adjusts its send rate when it needs to. The correct value for Usafe seems very much dependent on the receivers partialSNPInterval. It's so dependent that one might imagine it would be smart for the receiver to signal the value to the transmitter so that the transmitter can set Usafe correctly.

Thanks,
Chris.
[as WG member]

>
>    Les (claws in check 😊 )
>
>
> From: Tony Przygienda <[email-masked]>
> Sent: Wednesday, February 19, 2020 11:25 AM
> To: Les Ginsberg (ginsberg) <[email-masked]>
> Cc: Peter Psenak (ppsenak) <[email-masked]>; Tony Li <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>
> Having worked for last couple of years on implementation of flooding speeds that converge LSDBs some order of magnitudes above today's speeds  ;-) here's a bunch of observations
>
> 1. TX side is easy and useful. My observation having gone quickly over the -ginsberg- draft is that you really want a better hysterisis there, it's bit too vertical and you will generate oscillations rather than walk around the equilibrium ;-)
> 2. Queue per interface is fairly trivial with modern implementation techniques and memory sizes if done correctly. Yes, very memory constrained platforms are a mildly different game and kind of precondition a different discussion.
> 3. RX side is possible and somewhat useful but much harder to do well depending on flavor. If we're talking about the RX advertising a very static value to cap the flooding speed that's actually a useful knob to have IMO/IME. Trying to cleverly communicate to the TXer a window size is not only fiendishly difficult, incurs back propagation speed (not neglectible @ those rates IME) but can easily lead to subtle flood starvation behaviors and lots of slow starts due to mixture of control loop dynamics and implementation complexity of such a scheme. Though, giving the TXer some hint that a backpressure is desired is however not a bad thing IME and can be derived failry easily without needs for checking queue sizes and so on. It's observable by looking @ some standard stats on what is productive incoming rate on the interface. Anything smarter needs new TLVs on packets & then you have a problem under/oversampling based on hellos (too low a frequency) and ACKs (too bursty, too batchy) and flooded back LSPs (too unpredictable)
>
> For more details I can recommend rift draft of course ;-)
>
> otherwise I'm staying out from this mildly feline spat ;-)
>
> --- tony
>
> On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>> wrote:
> Tony -
>
> Peter has a done a great job of highlighting that "single queue" is an oversimplification - I have nothing to add to that discussion.
>
> I would like to point out another aspect of the Rx based solution.
>
> As you need to send signaling based upon dynamic receiver state and this signaling is contained in unreliable PDUs (hellos) and to be useful this signaling needs to be sent ASAP - you cannot wait until the next periodic hello interval (default 10 seconds) to expire. So you are going to have to introduce extra hello traffic at a time when protocol input queues are already stressed.
>
> Given hellos are unreliable, the question of how many transmissions of the update flow info is enough arises. You could make this more deterministic by enhancing the new TLV to include information received from the neighbor so that each side would know when the neighbor had received the updated info. This then requires additional hellos be sent in both directions - which exacerbates the queue issues on both receiver and transmitter.
>
> It is true (of course) that hellos should be treated with higher priority than other PDUs, but this does not mean that the additional hellos have no impact on the queue space available for LSPs/SNPs.
>
> Also, it seems like you are proposing interface independent logic, so you will be adjusting flow information on all interfaces enabled for IS-IS, which means that additional hello traffic will occur on all interfaces. At scale this is concerning.
>
>    Les
>
>
>> -----Original Message-----
>> From: Peter Psenak <[email-masked]<mailto:[email-masked]>>
>> Sent: Wednesday, February 19, 2020 2:49 AM
>> To: Tony Li <[email-masked]<mailto:[email-masked]>>
>> Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
>> [email-masked]<mailto:[email-masked]>
>> Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed
>>
>> Tony,
>>
>> On 19/02/2020 11:37, Tony Li wrote:
>> > Peter,
>> >
>> >> I'm aware of the PD layer and that is not the issue. The problem is that
>> there is no common value to report across different PD layers, as each
>> architecture may have different number of queues involved, etc. Trying to
>> find a common value to report to IPGs across various PDs would involve
>> some PD specific logic and that is the part I'm referring to and I would like
>> NOT to get into.
>> >
>> >
>> > I’m sorry that scares you.  It would seem like an initial implementation
>> might be to take the min of the free space of the queues leading from the
>> >interface to the CPU. I grant you that some additional sophistication may be
>> necessary, but I suspect that this is not going to become more >complicated
>> than polynomial evaluation.
>>
>> I'm not scared of polynomial evaluation, but the fact that my IGP
>> implementation is dependent on the PD specifics, which are not generally
>> available and need to be custom built for each PD specifically. I always
>> thought a good IGP implementation is PD agnostic.
>>
>> thanks,
>> Peter
>>
>> >
>> > Tony
>> >
>> > _______________________________________________
>> > Lsr mailing list
>> > [email-masked]<mailto:[email-masked]>
>> > https://www.ietf.org/mailman/listinfo/lsr
>> >
>> >
>
> _______________________________________________
> Lsr mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/lsr
> _______________________________________________
> Lsr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsr

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 10 Mar 2020 08:22:36 -0700

Hey Christian, MaxTX is not that hard to derive since it's basically
limited by the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the
previous email what I think is useful and can be done ... BTW, timestamps
are useless unless you synchronize clocks and with all the queing that ISIS
does through the system normally to get stuff done it is very hard to
account for delays between packet being generated (or rx'ed on interface)
and last queue it's pulled from usually. More musings below backed by good
amount of work & empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't
the optimal idea that has bitten us back endless amount of times for the
shortcut it was ;-) then de facto, no real heavy duty IP box is using stock
TCP stack, at least in the scope of experience I have across bunch of
leading vendors. If you worked on mod'ing TCP for convergence speed with
BGP and cute little things like GR/NSR you will know the practical problems
and also why stock TCP is actually fairly underwhelming when it comes to
push large amounts of control data around (mod' distro, mod rusty 2c, mod
etc but that's my data).

And agreed, control theory is a wonderful thing and transfer windowing
protocols etc are long research if you know where to look and lots of the
stuff is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340
and so on. All of them are quite a lot of stuff to put into ISIS/link-state
and mostly do not do precisely what we need or precondition things we can't
afford under heavy load (very fast, non slip timers which are absolutely
non trivial if you're not in kernel). On top of that you'd need to drag 2
protocol transports around now with old ISIS flooding with RE-TX and and
the new thing that should be doing the stuff by itself (and negotiate
transport on top and so on). To give you a rought idea DDCP which is
probably smallest is ~ 10KLOC of C in user space in BETA and zero docs ;-)
I looked @ the practically existing stuff 2+ years ago in detail when doing
RIFT ;-) and with all what I practically found I ended up carving out the
pieces we need for fast flooding without introducing fast-acks which IMO
would be a non-starter for high scale link-state or rather, if we really
want that, the loop closes and we should go practically speaking to TCP (or
4340 which looked like a better choice to me but  just like e.g. Open-R did
and be done with it) or wait for the mythical QUIC all-singing-all-dancing
public domain implementation maybe. For many reasons I do not think it
would be a particularly good development entangling a control protocol
again with a user transport in the whole ball of yarn that IP is already.

kind of all I had to say, next thing ;-)

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps <[email-masked]> wrote:

> > As this is a local matter there is no interoperability issue, but
> certainly documenting a better algorithm is worthwhile.
>
> [as WG member]
>
> The main thing I'm afraid of is we're just making up some new overly
> simple congestion control algorithm (are there CC experts reviewing this?);
> maybe simulate it a few ways, deploy it, and have it work poorly or make
> things worse. In any case, damn the torpedos...
>
> In this current algorithm how does MaxLSPTx get set? What happens if
> MaxLSPTx is too high? If its too low we could be missing a much faster
> convergence capability.
>
> What if we had more quality information from the receiver, could we do a
> better job here? Maybe faster ACKs, or could we include a timestamp somehow
> to calculate RTT? This is the type of data that is used by existing CC
> algorithms (https://tools.ietf.org/html/rfc4342,
> https://tools.ietf.org/html/rfc5348). Of course going through these
> documents (which I've had to do for in another area) can start making one
> think "Punt to TCP" :)
>
> What would be nice, if we're going to attempt CC, is that the algorithm
> would be good enough to send relatively fast to start, adjust quickly if
> need be, and allow for *increasing* the send rate. The increasing part I
> think is important, if we take this work on, and I don't think it's
> currently covered.
>
> I also don't have a good feel for how quickly the current suggested
> algorithm adjusts its send rate when it needs to. The correct value for
> Usafe seems very much dependent on the receivers partialSNPInterval. It's
> so dependent that one might imagine it would be smart for the receiver to
> signal the value to the transmitter so that the transmitter can set Usafe
> correctly.
>
> Thanks,
> Chris.
> [as WG member]
>
>
>
> >
> >    Les (claws in check 😊 )
> >
> >
> > Cc: Peter Psenak (ppsenak) <[email-masked]>; Tony Li <
> [email-masked]>; [email-masked]; [email-masked]
> > Having worked for last couple of years on implementation of flooding
> speeds that converge LSDBs some order of magnitudes above today's speeds
> ;-) here's a bunch of observations
> >
> > 1. TX side is easy and useful. My observation having gone quickly over
> the -ginsberg- draft is that you really want a better hysterisis there,
> it's bit too vertical and you will generate oscillations rather than walk
> around the equilibrium ;-)
> > 2. Queue per interface is fairly trivial with modern implementation
> techniques and memory sizes if done correctly. Yes, very memory constrained
> platforms are a mildly different game and kind of precondition a different
> discussion.
> > 3. RX side is possible and somewhat useful but much harder to do well
> depending on flavor. If we're talking about the RX advertising a very
> static value to cap the flooding speed that's actually a useful knob to
> have IMO/IME. Trying to cleverly communicate to the TXer a window size is
> not only fiendishly difficult, incurs back propagation speed (not
> neglectible @ those rates IME) but can easily lead to subtle flood
> starvation behaviors and lots of slow starts due to mixture of control loop
> dynamics and implementation complexity of such a scheme. Though, giving the
> TXer some hint that a backpressure is desired is however not a bad thing
> IME and can be derived failry easily without needs for checking queue sizes
> and so on. It's observable by looking @ some standard stats on what is
> productive incoming rate on the interface. Anything smarter needs new TLVs
> on packets & then you have a problem under/oversampling based on hellos
> (too low a frequency) and ACKs (too bursty, too batchy) and flooded back
> LSPs (too unpredictable)
> >
> > On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <
> [email-masked]<mailto:[email-masked]>> wrote:
> > Tony -
> >
> > Peter has a done a great job of highlighting that "single queue" is an
> oversimplification - I have nothing to add to that discussion.
> >
> > As you need to send signaling based upon dynamic receiver state and this
> signaling is contained in unreliable PDUs (hellos) and to be useful this
> signaling needs to be sent ASAP - you cannot wait until the next periodic
> hello interval (default 10 seconds) to expire. So you are going to have to
> introduce extra hello traffic at a time when protocol input queues are
> already stressed.
> >
> > Given hellos are unreliable, the question of how many transmissions of
> the update flow info is enough arises. You could make this more
> deterministic by enhancing the new TLV to include information received from
> the neighbor so that each side would know when the neighbor had received
> the updated info. This then requires additional hellos be sent in both
> directions - which exacerbates the queue issues on both receiver and
> transmitter.
> >
> > It is true (of course) that hellos should be treated with higher
> priority than other PDUs, but this does not mean that the additional hellos
> have no impact on the queue space available for LSPs/SNPs.
> >
> > Also, it seems like you are proposing interface independent logic, so
> you will be adjusting flow information on all interfaces enabled for IS-IS,
> which means that additional hello traffic will occur on all interfaces. At
> scale this is concerning.
> >
> >    Les
> >
> >
> >> Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:
> [email-masked]>>; [email-masked]<mailto:[email-masked]>;
> >> necessary, but I suspect that this is not going to become more
> >complicated

---

From: <[email-masked]>
Date: Tue, 10 Mar 2020 16:43:37 +0000

With regards to punting to TCP, I think that TCP (stacks) enforce packet ordering.
i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1 until you receive packet 2. In the meantime, you cannot use the (N-2) packets that you did received.
That seems like a regression for IS-IS which doesn’t requiring LSPs ordering. (vs BGP).

Also, from what I’ve been told from BGP implementers, TCP is not magic and can’t be treated as a black box (if you want scale/performance).

1 cent
--Bruno

From: Lsr [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Tuesday, March 10, 2020 4:23 PM
To: Christian Hopps
Cc: [email-masked]; [email-masked]; Tony Li; Peter Psenak (ppsenak)
Subject: Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

Hey Christian, MaxTX is not that hard to derive since it's basically limited by the local system and its CPU/prioritization/queing architecture.

For the rest of your email, in short, you have my observations in the previous email what I think is useful and can be done ... BTW, timestamps are useless unless you synchronize clocks and with all the queing that ISIS does through the system normally to get stuff done it is very hard to account for delays between packet being generated (or rx'ed on interface) and last queue it's pulled from usually. More musings below backed by good amount of work & empirical experience ;-)

If we try to punt to TCP (like BGP did in its time which I argued wasn't the optimal idea that has bitten us back endless amount of times for the shortcut it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, at least in the scope of experience I have across bunch of leading vendors. If you worked on mod'ing TCP for convergence speed with BGP and cute little things like GR/NSR you will know the practical problems and also why stock TCP is actually fairly underwhelming when it comes to push large amounts of control data around (mod' distro, mod rusty 2c, mod etc but that's my data)..

And agreed, control theory is a wonderful thing and transfer windowing protocols etc are long research if you know where to look and lots of the stuff is e.g. present in TCP, QUIC or https://tools.ietf.org/html/rfc4340 and so on. All of them are quite a lot of stuff to put into ISIS/link-state and mostly do not do precisely what we need or precondition things we can't afford under heavy load (very fast, non slip timers which are absolutely non trivial if you're not in kernel). On top of that you'd need to drag 2 protocol transports around now with old ISIS flooding with RE-TX and and the new thing that should be doing the stuff by itself (and negotiate transport on top and so on). To give you a rought idea DDCP which is probably smallest is ~ 10KLOC of C in user space in BETA and zero docs ;-) I looked @ the practically existing stuff 2+ years ago in detail when doing RIFT ;-) and with all what I practically found I ended up carving out the pieces we need for fast flooding without introducing fast-acks which IMO would be a non-starter for high scale link-state or rather, if we really want that, the loop closes and we should go practically speaking to TCP (or 4340 which looked like a better choice to me but  just like e.g. Open-R did and be done with it) or wait for the mythical QUIC all-singing-all-dancing public domain implementation maybe. For many reasons I do not think it would be a particularly good development entangling a control protocol again with a user transport in the whole ball of yarn that IP is already.

--- tony

On Tue, Mar 10, 2020 at 7:48 AM Christian Hopps <[email-masked]<mailto:[email-masked]>> wrote:

[as WG member]

Thanks,
Chris.
[as WG member]

>
>    Les (claws in check 😊 )
>
>
> From: Tony Przygienda <[email-masked]<mailto:[email-masked]>>
> To: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]>>
> Cc: Peter Psenak (ppsenak) <[email-masked]<mailto:[email-masked]>>; Tony Li <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> On Wed, Feb 19, 2020 at 9:59 AM Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
> Tony -
>
>> From: Peter Psenak <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:ppsenak@cisco..com>>>
>> To: Tony Li <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
>> Cc: Les Ginsberg (ginsberg) <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>; [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>;
>> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
>> > [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 10 Mar 2020 10:02:28 -0700

On Tue, Mar 10, 2020 at 9:43 AM <[email-masked]> wrote:

> i.e. if you receive packets 1, 3,4, …,N, then you can only use packet 1
> until you receive packet 2. In the meantime, you cannot use the (N-2)
> packets that you did received.
>

well, TCP is a windowing protocol and they're hard and very
bandwidth*delay/loss/jitter sensitive and yes, TCP is reliable transport
and not unreliable like ISIS flooding is ... Having said that, insane
amount of work has been done on TCP variants in all kind of stacks &
flavors coming full circle from fast start to slow start to fast start
again ;-)

Stepping back a bit, what we have in ISIS is basically a DHT and the
fastest way to synchronize that AFAIS is bittorrent transport ;-) When
doing RIFT I looked @ their transport & one can learn a lot from that but
it's a brave new world compared to the esteemed 10589 ;-) If one does that
kind of transport well, it blows TCP perf away in good scenario but then,
if we look for something 'download-open-source-and-plugin' kind except some
10 years old DCCP code you ain't gonna find anything massively hardened,
small or easily pluggable into an ISIS implementation. modulo open source
quic i didn't check the state off for last year or so or some secret sauce
someone found or maybe some of the p2p code got modularized and documented
;-) ...

>
> Also, from what I’ve been told from BGP implementers, TCP is not magic and
> can’t be treated as a black box (if you want scale/performance).
>

that's a mild understatement if you ask me after having lived in the
trenches since 1995 or so ;-)  On the other hand, the work has been done
often already and could be piggy-backed on but then, we buy ourselves
mandatory IP addressing into ISIS transport and lots of other interesting,
undesirable things TCP does since it's not a hop-by-hop transport but
"something that always tries to find a way". And next thing we'll need
TCP-AO so beware what you wish for ;-)

--- tony

---

From: Christian Hopps <[email-masked]>
Date: Tue, 10 Mar 2020 18:39:44 -0400

> On Mar 10, 2020, at 11:22 AM, Tony Przygienda <[email-masked]> wrote:
> 

Well so the value is "Fast as you can?" then? It's a specific value "MaxLSPTx" in the algorithm in the document though and it doesn't say "fast as you can" :)

Maybe "Fast as you can" is OK, as long as we have some way to quickly adjust that and not keep returning to it so much that we lose more than we gain when the receiver has no way to handle it. This flooding traffic can be very bursty so taking too long to reach optimal isn't very good I would guess.

For the rest, I wasn't actually being serious about using TCP, and your points are valid. I think there's some good stuff to maybe be paid attention to in those TCP friendly algorithms, but they don't fit our needs close enough for copying. FWIW I did add the necessary on wire data and documentation to IPTFS (ipsecme) to actually implement the DCCP style congestion control, and will probably end up coding it, hopefully in less than 10k LOC -- I'll let you know. :)

My main reason for the mail was I do think the algorithm in the document can be improved, and the first and last part of my mail were some questions in that direction.

Thanks,
Chris.
[as wg member]

> 
> If we try to punt to TCP (like BGP did in its time which I argued wasn't the optimal idea that has bitten us back endless amount of times for the shortcut it was ;-) then de facto, no real heavy duty IP box is using stock TCP stack, at least in the scope of experience I have across bunch of leading vendors. If you worked on mod'ing TCP for convergence speed with BGP and cute little things like GR/NSR you will know the practical problems and also why stock TCP is actually fairly underwhelming when it comes to push large amounts of control data around (mod' distro, mod rusty 2c, mod etc but that's my data).
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 10 Mar 2020 18:17:03 -0700

well, e'thing can be improved. I found what I suggesed since Les asked
works well enough ... As they say, your mileage may vary

whatever you suggest as absolute value in MaxLPSTx will not hold up the
test of time, 10/sec was a great value in 80s ...

--- tony

On Tue, Mar 10, 2020 at 3:39 PM Christian Hopps <[email-masked]> wrote:

> Well so the value is "Fast as you can?" then? It's a specific value
> "MaxLSPTx" in the algorithm in the document though and it doesn't say "fast
> as you can" :)
>
> Maybe "Fast as you can" is OK, as long as we have some way to quickly
> adjust that and not keep returning to it so much that we lose more than we
> gain when the receiver has no way to handle it. This flooding traffic can
> be very bursty so taking too long to reach optimal isn't very good I would
> guess.
>
> For the rest, I wasn't actually being serious about using TCP, and your
> points are valid. I think there's some good stuff to maybe be paid
> attention to in those TCP friendly algorithms, but they don't fit our needs
> close enough for copying. FWIW I did add the necessary on wire data and
> documentation to IPTFS (ipsecme) to actually implement the DCCP style
> congestion control, and will probably end up coding it, hopefully in less
> than 10k LOC -- I'll let you know. :)
>
> My main reason for the mail was I do think the algorithm in the document
> can be improved, and the first and last part of my mail were some questions
> in that direction.
>
> Thanks,
> Chris.
> [as wg member]
>
> > > As you need to send signaling based upon dynamic receiver state and
> this signaling is contained in unreliable PDUs (hellos) and to be useful
> this signaling needs to be sent ASAP - you cannot wait until the next
> periodic hello interval (default 10 seconds) to expire. So you are going to
> have to introduce extra hello traffic at a time when protocol input queues
> are already stressed.
> > >