First of all I have a clarification question: The use the of flags TLV with the O flag is not clear to me. Is that also meant as a configuration parameter or is that supposed to be a subTLV that has to be sent together with the PSNP? If it is a configuration, doesn’t the receiver need to confirm that the configuration is used and how does that work in the LAN scenario where multiple configurations are used? If it has to be sent together with the PSNP, this needs to be clarified and it seem a bit strange to me that it is part of the same TLV. Or maybe I’m missing something completely about the flag? Then, generally thank you for considering overload and congestion carefully. Please see my many comments below, however, I think one important part is to ensure that the network/link doesn’t get normally overloaded with the parameter selected. You give some recommendation about parameters to use but not for all and, more importantly, it would be good to define boundaries for safe use. What’s a “safe” min or max value? I know this question is often not easy to answer, however, if you as the expert don’t give the right recommendations, how should a regular implementer make the right choice? Please see further comments below. Section 4.7: “NOTE: The focus of work used to develop the example algorithms discussed later in this document focused on operation over point-to-point interfaces. A full discussion of how best to do faster flooding on a LAN interface is therefore out of scope for this document.” Actually this is quite important and also not clear to me. You do discuss how to interpret parameters in a LAN scenario but then you say you only give proper guidance how to adjust the sending rate for non-LAN. But what’s the right thing to do in LAN then? Why is LAN out of scope? If you don’t give guidance, I think you have to also say that this mechanism that enables using higher values in this document MUST NOT be used on LAN setups. Section 5.1: “The receiver SHOULD reduce its partialSNPInterval. The choice of this lower value is a local choice. It may depend on the available processing power of the node, the number of adjacencies, and the requirement to synchronize the LSDB more quickly. 200 ms seems to be a reasonable value.” Giving some recommended value is fine, however, it would be more important to ensure safe operation to give a range or at least a minimum value. Also on use of normative language. Just saying “The receiver SHOULD reduce its partialSNPInterval.” Is a bit meaningless without saying when and to with value/by how much. I guess you should say something like “partialSNPInterval SHOULD be set to 200ms and MUST NOT be lower than X.” “The LPP SHOULD also be less than or equal to 90 as this is the maximum number of LSPs that can be acknowledged in a PSNP at common MTU sizes, hence waiting longer would not reduce the number of PSNPs sent but would delay the acknowledgements. Based on experimental evidence, 15 unacknowledged LSPs is a good value assuming that the Receive Window is at least 30 and that both the transmitter and receiver have reasonably fast CPUs.” Why is the first SHOULD a SHOULD and not a MUST? What is a reasonable fast CDU? Why would the receive window be 30? Is that also the value that you would recommend? So you maybe more generally aim to recommend to set the LPP to half the Receive Window (or does it have to be those specific values)? Section 5.2: “Therefore implementations SHOULD prioritize the receipt of Hellos and then SNPs over LSPs. Implementations MAY also prioritize IS-IS packets over other less critical protocols.” What do mean by prioritise exactly? I find the second sentence here meaningless when you only say “less critical protocols”. What do you mean by this? How should I as an implementer decide which protocols are more or less critical? Section 6.1: “Congestion control creates multiple interacting control loops between multiple transmitters and multiple receivers to prevent the transmitters from overwhelming the overall network.” This is an editorial comment: I think I know what you mean but the sentence is not clear as there is always only one congestion loop between one transmitter and one receiver. Section 6.2.1: “If no value is advertised, the transmitter should initialize rwin with its own local value.” I think you need to give more guidance anyway but a good buffer size might be. However, if you don’t know the other ends capability, I’m not sure if you own value is a good idea or if it would be better to be rather conservative and select a low value that still provides reasonable performance. Section 6.2.1.1: “The LSP transmitter MUST NOT exceed these parameters. After having sent a full burst of un-acknowledged LSPs, it MUST send the following LSPs with an LSP Transmission Interval between LSP transmissions. For CPU scheduling reasons, this rate may be averaged over a small period, e.g., 10-30ms.” I not sure I fully understand what you mean by “averaged over a small period”? What exactly? Section 6.2.1.2: “f no PSNPs have been generated on the LAN for a suitable period of time, then an LSP transmitter can safely set the number of un-acknowledged LSPs to zero. Since this suitable period of time is much higher than the fast acknowledgment of LSPs defined in Section 5.1, the sustainable transmission rate of LSPs will be much slower on a LAN interface than on a point-to-point interface.” What a suitable period of time? Can you be more concrete? Section 6.2.2.1 - As a side note, I don’t think figure 1 is useful at all… - cwin = LPP + 1: Why is LPP selected as the start/minimum value? Earlier on you say that LPP must be equal or less than 90 and recommend a value of 15. These values seem already large. Section 6.2.2.2: “This value should include a margin of error to avoid false positives (e.g., estimated MAT measure variance) which would have a significant impact on performance.” First, you call the first congestion signal “Timer” however I think it should be call “Loss” where the loss detection algorithm you are proposing is based on a timer. In TCP the retransmission (and therefore loss detection) timer is initially set to 3xRTT and then adapted with more measurements (see RFC6298). The text above, however, seems really too vague to implement that right. I guess you can take the simple approach and just set it to 3xRTT. However, given the delays on a point-to-point link are really small, I’m not sure a timer based on RTT is useful at all. Is the system even able to maintain a timer with that granularity? My understanding, however, is that LSP has a way to detect loss already in order to retransmit, therefore it would make more sense simply always reset the cwin when you retransmit a PDU. Or how does the LSP decide to send a retransmission? “Reordering: a sender can record its sending order and check that acknowledgements arrive in the same order as LSPs. This makes an additional assumption and should ideally be backed up by a confirmation by the receiver that this assumption stands.” Regarding re-ordering as an input: if a packet if “just” re-ordered but still received, it should not be talken as a congestion signal. However, can that even happen on a point-to-point link? If you mean the packet was never received and there is a gap in the packet number, that’s again called loss and not reordering, but simply using a packet number based detection mechanism instead of a timer. However, based on the description above it is not fully clear to me how you think this would work and what you mean by “additional assumption”…? I think you further need to clarify this. Sec 6.2.2.3: You call this refinement “Fast recovery” which I guess is inspired by TCP. However, it’s a bit confusing because in TCP i’st a different algorithm. In TCP’s fast recovery, you do not reduce your congestion window to the initial value but only halve it (or decrease by a different factor depending on the congestion control algorithm). This is done if only some packets are lost while most packets still arrive. In TCP, resetting to the initial value only happens if a timeout occurs, meaning no data/acks have arrives for some time. Sec 6.2.2.4: “The rates of increase were inspired from TCP [RFC5681], but it is possible that a different rate of increase for cwin in the congestion avoidance phase actually yields better results due to the low RTT values in most IS-IS deployments.” I don’t think this is really a refinement but rather some consideration. However, saying this without any further guidance, doesn’t seem really help or even harmful. However, more generally, all in all I’m also not sure a fine-grained congestion control is really needed on a point-to-point link as there is only one receiver that could be overload and in that case you should rather adapt your flow control. I think what you want is to set the flow control parameter in the first place in a reasonable range. If then there is actual congestion for some reason, meaning you detect a constant or increasing loss rate, maybe you want to implement some kind of circuit breaker by stop sending or fall-back to a minimum rate for a while (e.g. see RFC8085 section 3.1.10.). However why would that even happen on a point-point-link? Sec 6.2.3 “Senders SHOULD limit bursts to the initial congestion window.“ I don’t think this is a requirement because based on your specified algorithm this happens automatically. The initial window is LPP which is also the max number of PDUs that can be asked in on PSNP thus this is also the maximum number of packets you can sent out in receipt go the PSNP (given you don’t let the cwin growth beyond what’s ready to send). However, you have this new parameter for the LSP burst window. That’s what should limit the burst size (and be rather be smaller than LPP/the initial window). Also pacing is used over Internet link to avoid overloading small buffer on the path, as the buffer size of the network element is unknown. This is not the case in your point-to-point scenario. If you know all buffer sizes, it probably sufficient to limit the burst size accordingly. Sec 6.2.4 “If the values are too low then the transmitter will not use the full bandwidth or available CPU resources.” As a side note, I hope that fully utilising the link or CPU just with LSP traffic is not the goal here. Which is another reason my you might not need a fine-grained congestion control: congestion has two goals, avoid congestion but also fully utilise the link -> I think you only need the former. 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. Also because you interchangeably use the terms congestion control and flow control. 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. 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. Some small nits: - Sec 4: advertise flooding-related parameters parameters -> advertise flooding-related parameters - Sec 5.1: PSNP PDUs -> PSNPs or PSN PDUs - Sec 5.2: Sequence Number Packets (SNPs) -> probably: Sequence Number PDUs (SNPs)? - Sec 6.2.1.1.: leave space for CSNP and PSNP (SNP) PDUs -> leave space for CSNPs and PSNPs ?