>>> Another benefit with TCP is congestion control, with UDP if we send a >>> map-register and we don't get an ack then we retry. What if the MS is >>> fully subscribed then this can lead to constant retry. You can impose >>> backoff mechanism but ultimately this would affect convergence. >> And you think in this condition that TCP won’t be retrying. The arguments >> are weak. In fact, if TCP is retrying there is a greater window of time >> where old RLOC-set data is in the pipeline. > > From a general perspective if TCP is adapting to network impairments or > congestion in a given setting, any other solution will have to adapt too, so > the experienced delay/loss problems should be there too. But the advantage in > this case would be not having to re-implement an adaptive solution within the > LISP application itself, but taking advantage of a solution that already > provides this.
Let me make it perfectly clear. I am NOT against using TCP. We did it for PIM and thought it was a good idea. I have cc’ed Stig who has intimate knowledge and experience with PIM-over-TCP. Maybe he can comment. And we also have a lot of history with BGP-over-TCP. I am rebuttaling some of your reasons why. That’s all. > However, note that as Fabio and Johnson mentioned at the beginning of the > thread, both LISP encoding of messages and UDP based signaling are preserved > with the reliable transport implementation. xTRs that can take advantage of Right, that should be made more clear in the next revision to the draft. And looks like Fabio is already thinking of that (my reply is pending). Dino _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
