Hi Xuesong, > <Xuesong> I think there is no need to distinguish the concept of flow control > and congestion control, considering that the core idea is the same: monitor > the sending rate to match the capability of the bottleneck, no matter there > are competitors or not. And the control loop is necessary in both case.
This matches my perspective. > <Xuesong> Thank you for explaining about the bottleneck of flooding and > different cc solutions that are under discussion. It is helpful and I will > read the drafts. > There is still one more question left in the previous email: " What is the > criteria of comparing different solutions?". I think this is crucial for > further discussion and comparative tests. I notice that in Bruno's data, some > parameters are mentioned, such as " Duration"," LSP/second"," avg inter-LSP > delay", "retransmission time". I'm wondering whether it is able to choose a > better solution through these parameters. If not, what should be added or > considered. (Some other issues are also considered when choosing cc mechanism > in layer 4, such as: fairness among flows, co-existence with other cc > mechanism .. ) Sorry for missing the question. The criteria are, I think, quite clear: minimize overall flooding time. As Bruno’s figures show, that does NOT happen simply by transmitting at the maximum rate. That causes overruns, resulting in retransmissions and that ends up being quite slow (tho we can work on that too). The question then is: what control mechanisms do we put in place to ensure minimal flooding time? This needs to interoperate across the full spectrum of implementations: fast brand X needs to not overrun slow brand Y while performing well with fast brand Z. The floor is very much open. Tony _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
