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

[Joe Touch <[e-mail]>]

Curtis,

If you're going with this argument (SHOULD vs MUST), then you need to 
explain exactly *why* you're not doing what's recommended. "SHOULD" 
isn't carte blanche to claim an exception.

And the need to avoid layered congestion control is a good justification 
for not layering TCP-friendly on top of TCP-friendly, but not for 
avoiding circuit breaker-style congestion controls/limits.

Joe

On 1/21/2014 12:58 PM, Curtis Villamizar wrote:
> Lars,
>
> The IETF consensus in RFC5405 was to put a SHOULD in regarding use of
> congestion control in tunneling protocols.
>
> RFC2119 states:
>
>    3. SHOULD  This word, or the adjective "RECOMMENDED", mean that there
>       may exist valid reasons in particular circumstances to ignore a
>       particular item, but the full implications must be understood and
>       carefully weighed before choosing a different course.
>
> We have discussed the reasons why congestion control is in general a
> good thing.  We have also discussed why there may be valid reasons to
> not include congestion control in MPLS over UDP.
>
> The question is not whether there is already IETF consensus on
> congestion control in UDP in general.  There is consensus and that
> consensus was to use the word "SHOULD".
>
> The question we now face is whether MPLS in UDP needs to up the prior
> consensus to a MUST or can keep it as SHOULD.  I see one or maybe two
> people vigorously arguing to upgrade this to a MUST and otherwise
> consensus to keep this as SHOULD.  Further I see no objection except
> the same one or maybe two people to making the congestion control the
> topic of a later work if a need for it arises.  Consensus does not
> require unanimous agreeement.
>
> If we are trying to gauge consensus, maybe both you and I should sit
> back and let other people weigh in.
>
> Curtis
>
>
> In message <[e-mail]>
> "Eggert, Lars" writes:
>>
>> Hi,
>>
>> On 2014-1-17, at 18:19, Curtis Villamizar <[e-mail]> wrote:
>>> You have made your assertions about your desire to uphold the purity
>>> of any new UDP applications and adhere to the BCP you wrote.
>>> =20
>>> You appear to be very nearly alone in this argument and certainly no
>>> one that works with MPLS is siding with you.
>>
>> the reason we wrote the RFC when I was TSV AD was that we were seeing a =
>> whole bunch of questionable uses of UDP over the eyars and we were =
>> having the same arguments over and over. That's why we decided to write =
>> down the practices we expect users of UDP to follow. This is yet another =
>> such questionable use.
>>
>> (Also, I don't appreciate you turning this into a personal argument.)
>
> Nothing personal intended.
>
> The important point is the sentence "You appear to be very nearly
> alone in this argument and certainly no one that works with MPLS is
> siding with you." was intended to point out that there is no consensus
> behind your argument regardless of how vigorously you make that
> argument.
>
>>> In the end we can put anything we want in the RFC *but* IETF has never
>>> truly had the final word on what vendors and operators do in provider
>>> networks.
>>
>> Aka the "take my toys and go home" argument. Heard it many times.
>
> It has been successful many times in the past.  It turns into the "its
> deployed so get over it" argument after a few years.
>
>>> In this case, regardless of what changes are made to the draft,
>>> implementations will offer at least the option for non-RFC behavior by
>>> using zero checksums and not using any congestion control.  And
>>> providers will make use of it, perhaps exclusively.
>>
>> And there's nothing wrong with that - the BCP even says that one SHOULD =
>> NOT use congestion control for some deployment cases.
>>
>> But for others, one SHOULD. For those, a mechanism needs to be =
>> available, i.e., it needs to be specified and implemented.
>>
>>> The document might as well reflect reality, despite reality not
>>> conforming to your notions of architectural purity.
>>
>> I'm sorry, but we have certain architectural principles in the Internet =
>> that we have IETF consensus on. At least since RFC2914, that includes =
>> the need to have congestion control in place.
>>
>> There are always special deployment scenarios where these principles do =
>> not apply, and we typically explain in applicability statements when out =
>> specifications can only be safely used under certain conditions. I don't =
>> see any such statement in draft-ietf-mpls-in-udp, which to me means it's =
>> targeted at general Internet-wide use.
>>
>>> The best course of action is to put a SHOULD in regarding checksums
>>> and put a SHOULD in regarding congestion avoidance.  Even the BCP does
>>> not go any further than to say a tunneling protocol SHOULD use
>>> congestion control and there were reasons that the word MUST was not
>>> acceptable in the BCP.
>>
>> The SHOULD for congestion control needs to actually describe a mechanism =
>> that can be used when needed. It can't be a blanket "you SHOULD use =
>> something but we don't tell you what it is"-statement.
>>
>>> If we are still arguing over two instances of SHOULD vs MUST we have
>>> wasted a lot of bandwidth on those two words.
>>
>> It's not SHOULD vs. MUST. It's two SHOULDs, but in both cases it needs =
>> to be specified what is to be done. In the case of checksums, that's =
>> obvious (calculate it and check it); in the case of congestion control, =
>> some actual mechanism needs to be described (e.g., a circuit breaker).
>>
>>> IMHO The only remaining question is whether the document can go =
>> forward
>>> with the definition of congestion control for MPLS over UDP left out
>>> of scope and for another document if a need arises.
>>
>> In my opinion, it cannot.
>>
>>> If this is not acceptable to you (I doubt it is) please indicate what
>>> you would like to see in the document and since this is IETF last call
>>> where consensus matters and no one individual has veto power, we'll
>>> have to see if there is consensus behind your proposed changes.
>>
>> I would like the document to specify at the very least a circuit breaker =
>> mechanism, that stops the tunneled traffic if severe packet loss is =
>> detected along the path.
>>
>> And this isn't about an "individual veto". This is about a document that =
>> is at the moment in violation of IETF consensus at least as far back as =
>> RFC2914.
>>
>> Lars