Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPL

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 <B36BA2A8-0C28-4B88-87BD-51A6F964F893(_at_)netapp(_dot_)com>
> > > "Eggert, Lars" writes:
> > > > Hi,
> > > >
> > > > On 2014-1-17, at 18:19, Curtis Villamizar 
> > > > <curtis(_at_)ipv6(_dot_)occnc(_dot_)com> 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