Jeff, Right. Or a burst of large packets and a set of bursts of “regular sized” ones. My main point is that I’d like the spec to allow for flexibility in usage if you think it makes sense, and not be all-or-nothing.
Thanks! Thumb typed by Carlos Pignataro. Excuze typofraphicak errows 2019/09/13 8:10、Jeffrey Haas <jh...@pfrc.org>のメール: > Carlos, > > >> On Sep 12, 2019, at 10:56 PM, Carlos Pignataro (cpignata) >> <cpign...@cisco.com> wrote: >> >> Thanks for the reminder, Reshad. I support publication of this document, >> short and useful. >> >> I only have one comment in regards to: >> >> It is also worthy of note that even if an implementation can function >> with larger transport PDUs, that additional packet size may have >> impact on BFD scaling. Such systems may support a lower transmission >> interval (bfd.DesiredMinTxInterval) when operating in large packet >> mode. This interval may depend on the size of the transport PDU. >> >> Instead of (or in addition to) a lower transmission interval, why not add >> flexibility to not *have* to send large packets every packet, and instead >> send every n paks or so? > > Such a thing could be done. A form of this sort of thing for "probing" was > discussed in a prior draft I did with Xiao Min, but that was for Echo mode. > > But since this in BFD async mode, the timers are likely chosen for the worst > case. So, if we have the usual Detect Multiplier of 3 and we can support > sending a large packet every (e.g.) 25ms, and our implementation would > normally send smaller packets every 10ms, we'd need to negotiate for some > range between 10 and 25 knowing that the occasional large packet may itself > perturb timing enough it might be counted as loss. > > So, such a thing could be done by an implementation, but timing is messy. If > you want something a bit more occasional, I suggest a reasonable set of > timers in async mode and more clever procedures in Echo mode, if you support > that. > > -- Jeff >
