Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

[Scott Brim <[e-mail]>]

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 <[e-mail]> wrote:
>
> On Jan 14, 2014 6:00 AM, "Stewart Bryant" <[e-mail]> wrote:
>>
>> On 13/01/2014 19:09, Scott Brim wrote:
>>>
>>> On Mon, Jan 13, 2014 at 10:51 AM, Joel M. Halpern <[e-mail]>
>>> 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