Les,
> This thread reminds me of how easy it is to miscommunicate – and I bear some > of the responsibility for that. Communications takes two. The receiver must also be focused on the input. My bad too. > I don’t see anything in there about changing the PSNP signaling rate. From > your comments to Henk, I infer that you’re open to changing that rate. > [Les:] The proposal in the slides is simply an example/straw man. I did not > spend a lot of time on it – in fact in the first draft of the slides I did > not even provide a proposal. It certainly needs more refinement. > It is meant only to illustrate how we can do things w/o requiring the receive > side to do calculations for which the raw data may be difficult and w/o > requiring new TLVs. Understood. The difficulty in implementation is not our primary concern and something of a chicken and egg situation: if we do not ask to get the data about the input critical path, we will not get it. We’ve had a very similar situation with IP option handling: IP header options used to be very, very rare, so the first generation of forwarding ASICs passed off options for software-based forwarding. This made options slow. IPv6 designers then decided that options were slow, so they weren’t going to use options. ;-) If we need data from the platform silicon, then we should ask for it. We’re not going to get it if we don’t ask. And without specifics about what’s going on, we’re not going to make good approximations to the optimal rate. > As soon as you do that, you’re now providing receiver based feedback and > creating flow control. You’re accepting that rates will vary per interface. > > [Les:] Yes – but only when we know that continuing to send at a high rate > isn’t useful. It isn’t meant to fix things (as I keep emphasizing) and in a > network that works as intended it should never be necessary. Ok, below you say that you’re willing to be aggressive. But being aggressive means that we WILL push things into flow control. > What you’re NOT doing is providing information about the receiver’s input > queue and requested input rate. With less information, the transmitter can > only approximate the optimal rate and your proposal seems like a Newton’s > method approach to determining that rate. > > [Les:] For all of the implementations I have worked on (5 now – across 3 > different vendors – not all still available 😊 ) such information is not > easily determined. Buffer pools are shared among many components, input > queues may have multiple stages not all of which are visible to the routing > protocol. Plus, since once flow control is needed there is already a problem, > this isn’t fixing things – it is just trying to get by. > > A solution which depends on current receiver state “all the time” is hard – > and hard to optimize. And I think we don’t need that degree of precision for > optimal operation. No one is suggesting “all the time”. The point is to provide more information than what’s currently in the PSNP. The more information the transmitter has, the more accurately it can approximate the optimal transmit rate and maximize goodput. > Your proposal depends on two constants: Usafe and Umax. How do you know what > those are? > > [Les:] Not yet. That seems like a core problem. > That’s information about the receiver. > > [Les:] Happy to agree to that. Yay! One more thing that we agree on. :-) > I infer that you propose to hard code some conservative values for these. In > my mind, that implies that you will be going more slowly than you could if > you had more accurate data. And pretty much what we’re proposing is that the > receiver advertise this type of information so that we don’t have to assume > the worst case. This also is nice because an implementation only has to know > about it’s own capabilities. > > [Les:] I expect the values to be aggressive – because the downside of > flooding LSPs too fast for (say) a few seconds is small. Hmmm…. I’m not yet convinced. Elsewhere on the thread, you said that a good implementation should prioritize receiving IIHs over LSPs and *SNPs. I concur with that, but in my experience (5 vendors) I only know of one that implemented that in silicon, and that one’s not available (sob!). Thus, my concern is that without a good approximation for the goodput rate, we will either chronically underestimate, penalizing convergence, or chronically overestimate, risking the stability of the network. Tony
_______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
