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

[Joe Touch <[e-mail]>]

On 1/23/2014 7:20 PM, Curtis Villamizar wrote:
...
> Joe,
>
> I agree with you that the word SHOULD is not an automatic pass and
> quoted from RFC 2119 because I think that on this thread the criteria
> "valid reasons in particular circumstances" and "implications
> ... carefully weighed" have both been met.
>
> Perhaps you joined the discussion a little late.
>
> Please allow me to recap.  There are two issues under discussion, UDP
> checksums and congestion control.
>
> All parties seem to be OK with limiting the use of MPLS over UDP to
> service providers only within their own infrastructure only, except
> among cooperating service providers with explicit agreement
> (consenting adults).
>
> Within that context, some service providers find that parts of their
> infrastructure either doesn't support MPLS at all or doesn't support a
> usable variation of multipath for MPLS but does support IP ECMP (as I
> understand it, this is primarily in the fringes, access and less so
> edge - but someone who knows for sure please correct me if not).
>
> This eliminates the "expands the reach of MPLS argument".
>
> First UDP checksums:
>
>    The UDP checksum is at the beginning of the payload.  Please see
>    http://www.ietf.org/mail-archive/web/mpls/current/msg11279.html
>    This makes filling in a new UDP checksum infeasible on most high end
>    hardware.

That argument would make sense if most hardware wasn't store-and-forward 
on a per-packet basis.

>    Within all of that context, all of the links have at least 32 bit
>    FCS (either Ethernet framing or SONET or OTN) and some has much
>    better such as the FEC found in OTN.  This makes undetected
>    corruption by any of the links extremely unlikely.
>
>    Corruption internal to the router the only potential impact.  There
>    is good reason to think that this is extremely rare.

I don't buy the argument that per-hop checksums replace the need for 
end-to-end checksums; that's part of why more modern tunneling systems 
(e.g., SEAL) include their own head-to-tail checksum. So while I agree 
that UDP checksums may not be strong enough here, that might be an 
argument for a better tunneling mechanism than raw MPLS in IP, rather 
than ditching UDP checksums.

>    Infeasibility of doing UDP checksums in some instances (not just
>    performance concerns) is sufficient to make use of UDP checksums a
>    SHOULD.

Your argument hinges on feasibility, but that doesn't hold water (esp. 
given I've designed hardware that does Internet checksums - including 
some recent all-optical designs).

> On to congestion control:
>
>    Some MPLS payloads such as IP over MPLS have congestion control.
>    While it can't be assured that all IP traffic makes use of
>    congestion control, the problem is in the UDP services carried over
>    MPLS regardless of whether MPLS over UDP is used.

That is the key problem. As you point out below, other traffic is 
somewhat 'noise' on the overall equation.

>    The only other type of traffic carried by MPLS in any volume (not
>    counting ISIS control traffic carried as CLNP over MPLS, for
>    example) is PW.
>
>      PW in turn supports Ethernet, FR, ATM, TDM, and maybe a few
>      others.  The vast majority of payload in Ethernet, FR, ATM, is IP
>      so were are back to the prior bullet.  It PW packlet carrying
>      Ethernet, FR, or ATM are dropped the congestion response is
>      virtually identical to IP because the payload is IP.
>
>      The other PW case is TDM.  TDM serves two purposes in SP networks.
>      A small number of legacy customers circuits, generally T1 or T3
>      use it.  These are 1.5 and 45 Mb/s services on 1 Gb/s and 10 Gb/s
>      links.  Hardly a source of congestion, plus they pay a lot more
>      and therefore are priority traffic.  Another is 3G mobile
>      backhaul.  Again this is T1 or T3, but maybe as much as small
>      multiples of T3.  Still very low capacity.

You can't know whether the PW cases you expect will change over time, or 
are accurate as per above. I would not be surprised if someone started 
(or is already) using PW to connect datacenters to exchange bulk data 
using non-CC protocols.

>    TCP-like congestion control in a tunnel is very bad for any TCP
>    carried within the tunnel.  The vast majority on MPLS traffic is IP
>    and therefore is TCP.

Yes, and that's why nobody is asking for that.

>    Regardless of the weak argument in favor of it given the operational
>    reality, the authors have conceded to state that "MPLS over UDP
>    SHOULD have congestion control" in the document.

OK (that matches RFC 5405).

>    Because in the scenario it is intended to be deploy congestion
>    control is very unlikely to prove to be needed,

That's pure speculation, and more importantly undermines the SHOULD 
you've just conceded.

> defining the exact
>    form of congestion control is deferred to a later document which
>    will be written only if needed.

That document is needed now, exactly because of the SHOULD. You can't 
make a SHOULD recommendation without backing it up with the detail 
needed to implement it.

Other wise, it's a MAY, or (more to the point), a (nonexistent) MIGHT 
SOMEDAY.

> That said, I have in the past argued that the "circuit breaker" form
> of congestion control would be one of the worst things we could
> possibly do.  It would be terrible for TCP and most anything else.

Maybe, but if so, then you need the head-end to employ that breaker only 
on non-CC traffic.

> See http://www.ietf.org/mail-archive/web/mpls/current/msg11262.html
> The right place to put any circuit breaker would be TDM over PW, but
> given the capacities involved, that is not really needed either.
>
> In the past I've said:
>
>    The technical sticky point is knowing that the congestion is
>    occuring.  Perhaps a LM like packet on another UDP port could be
>    exchanged with the same caveats about inaccuracy if implemented in
>    software and inaccuracy if reordering occurs, and a recommendation
>    can be made to do something to introduce drop if congestion is
>    indicated by this method.  How to introduce drop should be an
>    implementation detail, a form of AQM or leaky bucket being possible
>    choices, but entirely a local matter.
>
> MPLS LM OAM would be a good choice for detection of congestion (as
> evidenced by loss).  A leaky bucket (aka shaper) likely with AQM seems
> like a reasonable choice.  This could be put into another document if
> a need ever truly arises for congestion control in MPLS and it could
> be applied to MPLS over anything (though it could prove impractical
> for MPLS over avian carrier).

See above. MIGHT SOMEDAY isn't a reasonable solution to a problem for 
which the need for a solution is already conceded.

Joe

>
> Curtis
>
>
>> 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