[+Les, Guillaume as we go quite deep in the discussion]

Hi Mirja,

Thank you for your review and comments. Very useful.

Please see inline [Bruno]
 
> From: Mirja Kühlewind via Datatracker <nore...@ietf.org> 
> Sent: Friday, February 2, 2024 3:57 PM
> 
> Reviewer: Mirja Kühlewind
> Review result: Not Ready
> 
> 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?

[Bruno] The O-flag is advertised by the receiver in the Flags sub-TLV, which 
may be sent either in PSNP or IIH.
That's not a configuration but a capability of the receiver which is signaled 
to the sender.
That's only applicable to the point-to-point scenario, not the LAN scenario. ( 
as on a LAN there is no explicit acknowledgment of the receipt of LSPs between 
a given LSP transmitter and a given LSP receiver).

> it seem a bit strange to me that it is part of the same TLV

[Bruno] 
All those sub-TLVs, at least the one currently defined, carries (relatively) 
static parameters and are not required to be sent in all IIH or PSNP. The way 
IS-IS acknowledges the reception of LSP is not changed
They are all grouped in a single TLV called " Flooding Parameters TLV" for 
grouping purpose and also because IS-IS has a limited TLV space.
If the above does not clarify, could you please elaborate on what you feel 
"strange" about?

 
> 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?

[Bruno]
Very fair points. And thank you for acknowledging that this question is not 
easy to answer...
TL;DR: sorry, I don't know.

Two general statements first:
- IS-IS is running in the control plane of two adjacent routers, typically in 
backbone of network operators. There is a single point to point link over fiber 
with typically latest interfaces speed (e.g. > 100G today). I would not assume 
that IS-IS would overload, or even significantly load this interface. From a 
jitter standpoint packet priority/CoS could be discussed but I would assume 
that I'm assuming that this is a different discussion.
- currently IS-IS has no flow control nor congestion control. Given this, 
current values are very conservative (e.g., one packet every 33ms). At the same 
time that's a very important signaling for the network: we would prefer not 
dropping LSP but on the other hand delaying LSP for seconds is not helping. For 
historically and good reasons IS-IS implementers are very conservative. As of 
today, I would not assume that they would be too aggressive.
- one problem of stating values in RFC is that those values may not age well. 
That's typically the case with IS-IS with some parameters values which are 
still 25 years old while CPU and networks have evolved significantly since 
then. So I'm a bit reluctant to write static values in stone again.

Coming back to min and max value:
- I'm not an implementor, but I do care about my networks. If I were an 
implementor, I would play safe and advertise values which are safe for my 
implementation as receiver. I would rather use those values as a protection 
from a too aggressive sender, than as a permission to overload (DOS) me. Both 
sender and receiver are within the same administrative domain (for certain). In 
case of issue, the network operator will debug both the sender and receiver and 
blame the one which did not behave.
- There are a wide range router size/price/capability/generation. Plus I would 
expect this value to gradually improve as the implementation improve thanks to 
the capabilities introduced by this document.
- I'm definitely not a transport/TCP expert. Does TCP define such min and max 
values?
 
We propose some guidance for the LPP (which is somewhat IS-IS specific) in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-5.1
But for other parameters, I'm not sure that indicating values would be useful.

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

[Bruno] In point-to-point there is one sender for one receiver. In LAN, there 
are N receivers for 1 sender, and possibly N senders for all/each receiver. The 
guidance is whether the multiplicative factor is to be handled by the sender or 
the receiver. Document says that the value is used by the sender as-is, so it's 
up to the receiver to take into account the number of speaker on the LAN. This 
guidance seems required for correct semantic.

Then the TLV may carries different sub-TLVs. Some may be applicable to LAN 
(e.g., Burst Size).
Some are less applicable to LAN because the way IS-IS acknowledge LSP is 
different in LAN and less dynamic. The LAN case is both less frequent those 
days (if not rare in backbones) and more difficult to handle as IS-IS 
acknowledges LSP in a slow and less explicit way hence we have a loose feedback 
loop to use. Eventually, someone could define new sub-TLV or procedure to 
improve the LAN case therefore I don't think that we should define TLV as not 
applicable to LAN.
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-6.2.1.2
 does partially discuss and cover the LAN case. Possibly the operation would be 
further improved, but I think that it's too late to add specification for the 
LAN . This may be covered in a subsequent doc. (but really LAN is not a 
priority those days)


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

[Bruno] Maximum value is defined in the "old" IS-IS spec. Minimal value seems 
very implementation specific to me.
More importantly, I don't think that safety comes into play but text could be 
more explicit on this. The goal is for the receiver to provide some "frequent" 
feedback to the sender so that the sender can adapter faster and hence be 
"safer": "Faster LSP flooding benefits from a faster feedback loop. This 
requires a reduction in the delay in sending PSNPs."
Nothing breaks if the receiver is too slow. Quite the contrary, the flow 
control algorithm would slow down, hence be on the safe side.

In order to be more explicit, I would propose the addition of the following 
text:
"The value of the "Partial SNP Interval sub-TLV" MAY be used by the sender for 
flow control and congestion control. It MUST NOT be used to trigger LSP 
retransmission."
I'd rather add this in section 4.5 which defines the sub-TLV
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#name-partial-snp-interval-sub-tl

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

[Bruno] Good point. Thank you. Proposed change:
OLD:  The receiver SHOULD reduce its partialSNPInterval.
NEW: For the generation of PSNPs, the receiver SHOULD use a partialSNPInterval 
smaller than the one defined in [ISO10589].

 
> “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?

[Bruno] The first "SHOULD" is a SHOULD because nothing breaks if it's not 
applied. Also the goal is for the receiver to provide frequent/fast feedback to 
the sender. If the throughput were very fast (e.g., 1Gb/s in a distant future), 
sending an acknowledgement (PSNP) every 90 LSPs would provide a feedback every 
1 ms which seem relatively responsive, especially compared to the link RTT in 
WAN. Possibly this could be rephrased to better focus on the need.
OLD:   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.
NEW:  The LPP SHOULD be less than or equal to the maximum number of LSPs that 
can be acknowledged in a PSNP because waiting longer would not reduce the 
number of PSNPs sent but would delay the acknowledgements. This is 90 at common 
MTU sizes. 

> What is a reasonable fast CDU?
Touché! That's the issue with indicating fixed value which will be outdated in 
the future. 
Proposed change:
OLD:   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.
NEW:  Based on experimental evidence, 15 unacknowledged LSPs is a good value 
assuming that the Receive Window is at least 30.

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

LPP value is discussed in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-6.2.2.5
I would propose to add 
NEW: The choice of the LPP value is discussed in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-6.2.2.5

To answer your questions:
- In tests, we found the LPP 15 is a good trade-of between increase feedback 
rate to the sender and increased load of acknowledging on both the receiver and 
sender.
- As indicated in 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-6.2.2.5
 for performance reasons its better if LPP is an integer fraction of the 
Receive Window. Hence choosing LPP 15 assume that the receive window is 30
- we don't recommend the receive window to be 30. In general, the larger the 
better for links with high RTT. However, this is a new concept for IS-IS and 
indicating a high number may afraid IS-IS implementation.  30 LSPs is a 45ko 
receive window which seems relatively small for a control plane memory (typical 
between a laptop and a small server) and for a critical protocol.
- I agree with you that setting LPP to half the receive window works fine. But 
a third would probably be even better with a large receive window. It really 
depends on the receive window and the goal is to provide a fast feedback: if 
the receive window is very large, we don’t necessarily want to delay PSNP too 
much.
- it definitely does not have to be a specific value.
- essentially, the LPP adds a delay to the feedback loop, in addition to the 
link RTT. (it adds "LSP sending rate"/LPP). Depending on the Receive Window and 
link RTT, LPP may reduce the achievable rate. But in many cases it would not. 
May be indicating that "desired LSP sending rate"/LPP be significantly smaller 
than link RTT would help the reader, but on the other hand I feel that it's a 
bit late for a change like this, unless you would support it given your 
experience in the transport area.



> 
> 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?

[Bruno] On routers, packets being transited are typically forwarded at line 
rate. But packets received from a set of very high-speed interfaces (e.g. 
aggregated received bandwidth of 10Tb/s) to the router's control plane (e.g. a 
laptop) face a significant bottleneck. Typically this bottleneck can give 
priority to some packets and may rate limit flows to protect from (D)DOS.
On one hand, relative priority between protocols is indeed a local choice of 
the implementer. Based on experience, he should know. I don't expect this to be 
novel, but as we increase the rate of IS-IS LSPs, the point is more important 
so we felt we should raise the point. To some extent, the question is the same 
for CPU allocation and scheduling. E.g., I would give more priority to IS-IS 
compared to BMP (monitoring) or even BGP even though BGP is an important 
routing protocol. Because essentially IS-IS is critical, the foundation of 
routing in the network and it's computation just assume that flooding is 
"perfect" so is sensitive to lack of global database consistency.
 
> 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.

[Bruno] Yes you know much better than us. Hence a suggestion would be welcomed 
😉.
I don't feel that the sentence contradicts your point as:
- I agree that "there is always only one congestion loop between one 
transmitter and one receiver"
- The sentence is trying to say that here are multiple senders hence multiple 
control loops. And that they affecting each other as they may compete for the 
same common resource on the way

We are trying to explain the different between flow control and congestion 
control, why both are useful and possibly why congestion control is harder. 
Suggestion is welcomed.

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

[Bruno] Actually we meant
OLD:  If no value is advertised, the transmitter should initialize rwin with 
its own local value.
NEW: If no value is advertised, the transmitter should initialize rwin with its 
locally configured value for this neighbor.

As 
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06#section-4
 says that if a value is not advertised, a locally configured value should be 
used.

I agree with you that more guidance would be helpful. Thank you for the comment.
Yet not completely easy especially for IS-IS as this is a new concept and 
different implementations may be very different. 

We could add the following text at the end of §6.2.1
NEW: The RWIN value is of importance when the RTT is the limitation. In this 
case the optimal size is the desired LSP rate divided by the RTT. The RTT being 
the addition of the link RTT plus the time taken by the receiver to acknowledge 
the first received LSP in its PSNP. 50 or 100 may be reasonable default numbers.

Comments and suggestion welcomed.
FYI:
- typical hardware is the equivalent of a high end laptop although RAM tend to 
be less restricted those days (e.g. 128GB)
- I would rate IS-IS as critical so would have priority 
- 100 IS-IS neighbhor seems a reasonable medium range
- 1k to 10k LSP/s would already be great.
- link RTT is very variable and depends to link distance. Could be 10km in 
dense area, 100s km in typical WAN in Europe, 1000 km seems high given country 
sizes and optical capabilities. Max would be intercontinental links crossing 
oceans.

> 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?

[Bruno] 
Rate is averaged over a small period (T) : #LSP during T / T. In which case 
during this period, burst is allowed.
e.g. with 100 LSP / 10 ms, one may send 10 LSPs every 1 ms rather than a strict 
1 LSP every 0.1ms.
In any case, the burst size is not to be exceeded.

If this is not clear, any suggestion welcomed.
 
> 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?

[Bruno] Good question. But difficult question.
Les, would you have some suggestion?
Otherwise, rather than adding more text for the LAN case, I'd rather remove 
some text with the following change

OLD:
However, an LSP transmitter on a LAN can infer whether any LSP receiver on the 
LAN has requested retransmission of LSPs from the DIS by monitoring PSNPs 
generated on the LAN. If 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.

NEW: /nothing/

As already stated, probably one could do better in the LAN case. E.g., 
advertising the delay between periodic CSNP (which would answer your question), 
sending in (LSP-ID) order, having the receiver send PSNP on a range of LSP-ID 
after a specific delay/LPP. But again, LAN is not seen as the priority in this 
document.
 
> Section 6.2.2.1
> 
> - As a side note, I don’t think figure 1 is useful at all…

[Bruno] OK. Note that Figure 2 is somewhat referring to Figure 1.
Would you suggest removing it entirely or adding more information. E.g. 
   +---------------+
   |               |
   |               v
   |     cwin = cwin0 = LPP + 1
   |   +----------------------+
   |   | Congestion avoidance |
         cwin increases as LSPs are acked
   |   + ---------------------+
   |               |
   |               | Congestion signal
   ----------------+

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

[Bruno] The receiver will not acknowledge anything before LPP LSPs are sent 
(*). In the absence of feedback the sender has no feedback loop and not even 
information about RTT. So we may shape the LSP being sent, but we do need to 
send LPP LSP to get some feedback. +1 is too allow for a loss of LSP.
(*) well it will acknowledge after a delay (Partial SNP Interval) but the 
suggested value is 200ms which seems significant and some implementation may 
not advertise this sub-TLV in which case default IS-IS value is in seconds. 

Retrospectively, we could have requested the received to quickly acknowledge 
the first received LSP (e.g., starting with LPP=1 and then increasing it). But 
we didn't and this may be seen as too late for a change. Still, adding this 
would not make existing implementation not compliant and may improve future 
evolutions. So I would welcome your feedback on this.
Also this argument is only applicable for the first iteration of congestion 
avoidance. Subsequent ones could have use information from the past.

Regarding cwin of 16, yes that's a significant start, but we know that the 
single link can largely handle this (>100Gbit/s), that diffserv Cos is enabled 
if needed, that some existing implementations blindly sends an initial burst of 
5 to 10 LSPs already (e.g., 10 for Cisco IOS "default optimized enabled" which 
is already years old)
https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwjNsuOpxZSEAxVHVaQEHVHuAhQQFnoECA4QAQ&url=https%3A%2F%2Fwww.cisco.com%2Fc%2Fen%2Fus%2Ftd%2Fdocs%2Fios-xml%2Fios%2Fseg_routing%2Fconfiguration%2Fxe-17%2Fsegrt-xe-17-book-cat8000%2Fsr-fast-convergence-default-optimize.pdf&usg=AOvVaw2phvrUtDUS1MdlO4E2eRZt&opi=89978449
 , that we are talking with a "carrier grade" router with a significant price 
tag and an assumed significant performance.
Even the 25 years old OSI specification allows for an initial burst of 10 
back-to-back LSP.

That being said, if we feel that this is not appropriate, the expertise is on 
you side, so please say so.

> 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?

[Bruno] Agreed with the name "Loss".
I'm personally fine with the proposed simple way of using 3*RTT. What about 
also referring to RFC6298?
Note that in our case, the timer is only used for detecting congestion. 
Retransmission uses a much larger timer (and is unchanged by this document)

Regarding link delay, within a dense area link delay would typically be 
"negligible". In WAN area, e.g., in France, link delay would easily be in the 
1ms - 10 ms range. Crossing the Atlantic Ocean is larger. Also, the RTT 
includes the time for IS-IS to acknowledge. I would assume that this may be 
significant (10 ms or may be more than 100ms) in some conditions such as if the 
routing process is handling both IS-IS flooding and BGP computations.)
In term of system timer granularity, this seems very implementation and 
condition specific.

Guillaume, please disagree if needed.

> 
> “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 taken 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.

[Bruno] IS-IS has no notion of packet number nor re-ordering. The receiver may 
acknowledge the LSP in any order.  The receiver acknowledges set of LPP LSPs 
and ordering in that set does not matter.
In addition, we don't want to change the way LSP are retransmitted. So we are 
ready to make a distinction between the loss message (e.g. not acknowledged 
within 5 seconds) and the congestion message (e.g., not acknowledged in order).
With regards to point to point interface, clearly the fiber will not reorder 
packet. There could be multiple Ethernet member "below" the IP layer but AFAIK 
a given flow should aways be sent on the same Ethernet member. (here flow would 
be based on the group mac address as IS-IS do not use IP). 

Trying to clarify
OLD:  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 holds. The O flag defined in Section 4.4 serves this 
purpose.
NEW: Reordering: if the receiver has signaled the O-flag (Ordered 
acknowledgement) (Section 4.4 ) a sender MAY record its sending order and check 
that acknowledgements arrive in the same order. If not this MAY be used to 
trigger a congestion signal.

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

[Bruno] Guillaume, any feedback on this?
One option is to remove those 2 refinements.
That being said, I feel like the text is readable even if it does not match TCP 
algorithm. If the name brings confusion it can be easily changed.


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

[Bruno] OK so this section could be removed.
 
> 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.

[Bruno] I fully agree with you. We have first implemented flow control and had 
very good results with it (no loss of LSP, very good adaptation of the sender 
rate to the receiver rate). We really had to purposely create congestion in 
order to have some congestion.
However, although there is a point to point link between adjacent routers, 
within the receiving routers there is typically a "switch" or a possible 
congestion between the N high speed incoming interfaces and the control plane 
(host). The feedback we received from multiple implementors is that the 
internal are platform dependent and touchy. They do experience some congestion 
on this path.
So we added congestion control and this does improve the situation I case of 
congestion.

> 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?

[Bruno] falling back to a minimum rate (current rate actually 😉) seems indeed 
like a simple and pragmatic solution. However if congestion happen frequently, 
this would significantly regrade performance. On the other hand, we found that 
reducing cwin was typically helpful. 
So may be we could remove both refinements and add that minimally the sender 
can falls back to the current rate of one LSP every 33 ms. (or whatever value 
used before this document)

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

[Bruno] OK. 
So is you proposal the below change?
OLD: Senders SHOULD limit bursts to the initial congestion window. A sender 
with knowledge that the receiver can absorb larger bursts, such as by receiving 
the LSP Burst Size sub-TLV from this receiver may use a higher limit.
NEW: Senders SHOULD limit bursts to LSP Burst Size.

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

[Bruno] Agreed but the capacity and behavior of the "internal switch" in the 
receiving router is unknown in general and people don't want to know it to 
allow control plane implementation to be platform independent.
Also a receiver may be connected to 100 other IS-IS routers sending their LSPs 
and the buffer size may be shared by all senders. So it seemed like pacing 
would be a good thing in the general case.

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

[Bruno] You are correct that fully utilizing the link or the CPU is not the 
goal. I would even say that fully utilizing the link would be well above the 
capability of IS-IS. But in our tests we achieved fully utilizing the CPU on 
the receiver when the used 10 senders in parallel. So essentially each sender 
was using 10% CPU of the receiver. But this included all the extra work done by 
IS-IS. And we had no loss of LSPs and the rate of each sender was controller by 
the rate of the receiver (just by using flow control, so no magic but still 
very efficient)

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

[Bruno] I agree with you.
That section served two purposes:
-  to indicate that the signaling specified on the receiver side (defined in 
sections 4 and 5) may actually be used by different congestion control 
algorithms.
- as the result of a compromise when we had to merge two competing proposals at 
the time of WG adoption.

Les and Marek, it's up to you to reply on your section.

Alternatively, the last paragraph of section 6.1 "Overview" probably already 
covers the first objective and to be transparent, the sentence is inspired from 
RFC 9002 section 7. (QUIC Loss Detection and Congestion Control).
And for the second objective, the text could possibly be moved to another 
document. But we would probably need WG feedback on this.

 
> 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  ?

[Bruno] Thank you for your careful review (of ISO terms...). Corrected.


Again thank you very much for your careful review. Much appreciated and much 
useful.
I'll upload a new version of the draft once we have converged or whenever you 
believe that this would help (e.g., when you ack a significant set of the 
proposed changes).

Best regards,
--Bruno

 
> 
>
____________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Reply via email to