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.com@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.

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

Mirja

> 
>   Les
> _______________________________________________
> Tsv-art mailing list
> Tsv-art@ietf.org
> https://www.ietf.org/mailman/listinfo/tsv-art