Hi Robert,
> Are you working on the assumption that there is no data link layer flow > control already which could signal the OS congestion on the receiving end ? I am assuming that there is no link layer flow control. I can’t recall working on a system that supports X.25 since about 1995, so I don’t think that’s a common use case today. > Are we also working on the assumptions that when ISIS PDUs are send in DCs > (unknown today case when out of the sudden 1000s of LSPs may need to get > flooded) use of some L4 fancy flow control is an overkill and we must invent > new essentially L2 flow control to cover this case to address partition > repair ? I am not assuming that the issue is restricted to the DC. Flooding is an issue in all IS-IS networks. 1000s of LSPs can occur in any IS-IS network of significant scale. All it takes is healing a partition and there can easily be a large number of LSPs to transmit. The case of 1000s of LSPs is of interest because the scale magnifies the flooding problem. If we only have one LSP that needs flooding, this entire discussion is moot. I am assuming that we want to go faster. That does seem to be something that we have agreement on. I am assuming that we dont’ want to go too fast. Overrunning the receiver is wasteful. I think we all agree on that. I am not assuming that we have to use some ‘L4 fancy flow control’, but I am trying to get a reasonable approximation to optimal goodput, with errors being on the conservative side (i.e., not overrunning the receiver). My understanding of control theory is pretty rudimentary, but what I do know is that it is going to be very difficult to achieve high goodput without a control loop of some flavor. I’m open to how we do this. Henk proposed that we simply pick up TCP for this, but my concern with that is really about introducing a whole new dependency to the protocol. That’s a lot to chew. Do we really need it all? I hope not. Thus, Bruno’s original suggestion sparked my interest in doing something dynamic and simple. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
