Mirja - Please see inline. LES2:
> -----Original Message----- > From: Mirja Kuehlewind (IETF) <i...@kuehlewind.net> > Sent: Thursday, February 8, 2024 5:11 AM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: tsv-...@ietf.org; draft-ietf-lsr-isis-fast-flooding....@ietf.org; > lsr@ietf.org > 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=40cisco....@dmarc.ietf.org> 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 > > tsv-...@ietf.org > > https://www.ietf.org/mailman/listinfo/tsv-art _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
