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

[Tony Przygienda <[e-mail]>]

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) <[e-mail]>
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 <[e-mail]>
> > Sent: Wednesday, February 19, 2020 2:49 AM
> > To: Tony Li <[e-mail]>
> > Cc: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail];
> > [e-mail]
> > 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
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/lsr
> > >
> > >
>
> _______________________________________________
> Lsr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lsr
>