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

In message <52E18810(_dot_)1010701(_at_)isi(_dot_)edu>
Joe Touch writes:
 
> 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

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.

  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.

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

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.

  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.

  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.

  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.

  Because in the scenario it is intended to be deploy congestion
  control is very unlikely to prove to be needed, defining the exact
  form of congestion control is deferred to a later document which
  will be written only if needed.

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.
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).

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