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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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
> >
> >