Re: [Tsv-art] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06

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

Mirja -

Please see inline.
LES2:

> -----Original Message-----
> From: Mirja Kuehlewind (IETF) <[e-mail]>
> Sent: Thursday, February 8, 2024 5:11 AM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Tsv-art] Tsvart early review of draft-ietf-lsr-isis-fast-flooding-06
> 
> Hi Les!
> 
> Please see below.
> 
> > On 5. Feb 2024, at 23:28, Les Ginsberg (ginsberg)
> <ginsberg=[e-mail]> wrote:
> >
> > Mirja -
> >
> > In regards to Section 6.3...
> >
> >
> >>
> >> Sec 6.3
> >> This section is entirely not clear to me. There is no algorithm described and I
> >> would not know how to implement this.
> >
> > [LES:] This is intentional.
> > As this approach is NOT dependent on any signaling from the receiver, the
> transmitter is free to implement in whatever manner it finds effective - there
> are no interoperability issues.
> > As we state:
> >
> > "Such an algorithm is a local matter and there is no requirement or intent to
> standardize an algorithm."
> 
> Yes, this does not be standardised but if you talk about it you need to explain it
> in enough detail that people can impelemt something use. Other I don’t see a
> point about having this section at all.
> 

[LES2:] We explain the behavior.
The actual implementation is - at least for now - proprietary.
So yes - exactly "how" the requirements are met is not discussed.
But folks who are "skilled in the art" should be able to use this as a guide to developing their own implementation.

> >
> >> Also because you interchangeably
> >> use the
> >> terms congestion control and flow control.
> >
> > [LES:]  Good point.
> > I believe we should use the term "congestion control" throughout this
> section.
> > Will work with Bruno to make that change.
> >
> >> Further you say that no input
> >> signal
> >> from the receiver is needed, however, if you want to send with the rate of
> >> acknowledgement received that is an input from the receiver.
> >
> > [LES:] The use of the neighbor partialSNPInterval sub-TLV (Section 4.5) is
> optional.
> > It may be useful, but as our intention is to have the algorithm work with
> legacy neighbors who do not support the additional advertisements defined in
> this document, it is necessary that the algorithm work well even in the absence
> of that signaling.
> > If by "rate of acknowledgement ...is an input from the receiver" you think we
> are contradicting ourselves, I will gently pushback.
> > We have not changed the operation of the Update Process in any way. So
> the acks we receive and the rate at which they were received is information
> which is available today from current operation of the Update Process. To date
> it just hasn’t been used to influence transmission rate of other LSPs - it has
> only been used to cancel retransmissions on the LSPs already sent.
> >
> > [ >However, the
> >> window based TCP-like algorithms does actually implicitly exactly that: it
> only
> >> send new data if an acknowledgement is received. It further also takes the
> >> number of PDUs that are acknowledged into account because that can be
> >> configured. If you don’t do that, you sending rate will get lower and lower.
> >>
> > [LES:] Paragraphs 4, 5, 6 discuss both slowing down the transmission rate
> and speeding up the transmission rate. The algorithm needs to do both - and
> does so based on the actual performance i.e., how quickly ACKs have been
> received.
> > Paragraph 6 highlights that we cannot assume that performance is static. If
> you think that once we slow down we will never speed up then please reread
> Paragraph 5.
> >
> > At the risk of repeating myself, I emphasize that lack of dependence on
> signaling by the receiver is a key element of this approach which enables it to
> work with both legacy and upgraded nodes.
> 
> I think we have a terminology problem here. I say the ack rate is a signal from
> the receiver; you say there is no additional saviour change needed in order to
> get this single. I agree that is an important point but to me that not what the
> text says (because rate IS a signal). In summary I think what need is to
> improve the wording to make this clear (to all of us).
> 
[LES2:] There is no signal of ack rate being sent. Normal operation of the IS-IS Update process requires receivers to send ACKs (in PSNPs) to the transmitter.
"ack rate" can be tracked by the transmitter simply by keeping a history of the number of LSP acknowledgements it has received over a multi-second period.
I think it would be misleading to characterize the sending of PSNPs as a "signal of ack rate". 

Hope this makes sense.

  Les

> Mirja
> 
> 
> 
> 
> >
> >   Les
> > _______________________________________________
> > Tsv-art mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tsv-art