Hi Les! Please see below.
> On 5. Feb 2024, at 23:28, Les Ginsberg (ginsberg) > <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tsv-art _______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
