Now that I'm at a real keyboard, and since at least one person didn't get what I was trying to say with my reference, let me try to explain more clearly. Transport is pretty arcane. We sometimes get it more or less right when we're dealing with a single instance of it in endpoints and routers/switches. In this case, if we add congestion management to the encapsulating UDP, we have two possible instances of the same function stacked on top of each other, where each has no way of knowing whether the other exists, if so what it's doing, or if there's any way to communicate with it. We have examples in the past where we have got this badly wrong. IMHO this is more likely to be a problem than not. The best architectural answer I can think of in this case is the one with the least surprises built in: treat the lower level UDP as just an encapsulation, not an intelligent transport protocol. Yes there should be scope for congestion management but that is higher up, where the endpoints come in to play. Scott On Tue, Jan 14, 2014 at 8:11 AM, Scott Brim <scott.brim@xxxxxxxxx> wrote: > > On Jan 14, 2014 6:00 AM, "Stewart Bryant" <stbryant@xxxxxxxxx> wrote: >> >> On 13/01/2014 19:09, Scott Brim wrote: >>> >>> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern <jmh@xxxxxxxxxxxxxxx> >>> wrote: >>> I'm concerned about TCP-over-X.25 scenarios. >> >> ... and how many b/s of that exist in the universe! > > Stewart: none that I know of, of course, but it was in production at a > significant time in Internet history and was one of our first experiences > with multiple layers each trying to provide transport control and thereby > destroying goodput. I'll never forget it. When I think of two layers each > trying to do congestion management, with no way to coordinate with each > other, that's the first example that comes to mind. > > Scott