Subject: [mpls] Progressing foo-over-UDP

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 22 Jul 2014 13:56:50 +0100

In London I took an action to write up suggested text for how to handle the
concerns of congestion and checksum in UDP-over-foo.

I think we had some agreement of what was needed (look at the minutes of TSVWG -
or was it TSV Area? - from London).

Of course, I have let you all down. I have about 75% of the necessary text for
MPLS-over-UDP (as a concrete example), but I am not complete. You don't need to
know my excuses.

Attached below (so you can laugh at me) is the text I have so far. it is work in
progress, but since I am currently getting in the way, some of you might want to
take the pen (if no-one wants to, I will try to continue and complete this).

Cheers,
Adrian

==================

x.  Applicability and Deployment of MPLS-in-UDP

   It is helpful to categorise the type of networks in which this
   solution might be deployed.  That is, it is useful to look at the
   type of network over which the UDP tunnel might run, and the type of
   network that may be running MPLS.  An understanding of these 
   categories will lead to the realization that deploying MPLS-in-UDP in
   some environments is entirely safe, in other scenarios might cause 
   issues to the networks involved but is a local choice for the 
   operators of those networks, while in other situations the deployment
   might be significantly harmful to other services or traffic outside
   the responsibility of the operator deploying MPLS-in-UDP.

   In broad terms these deployment categories can be listed as follows:

   - Tunneling across the Internet
   - Tunneling over a provider network in a customer/provider
     relationship
   - Tunneling in a client/server relationship owned by a single
     operator
   - Tunneling within a "flat" network

   The remainder of this section describes the deployment of MPLS-in-UDP
   in these networks, and gives warnings, advice, and caveats
   appropriate to those scenarios with special reference to congestion
   avoidance and the use of checksums.  The use made of MPLS-in-UDP by
   applications must be cognisant of the underlying network deployment.
   However, it needs to be understood that an end-point application is
   generally unaware of the services or connectivity over which it is
   sending data.  That is, an end-point application is sending IP data
   possibly using TCP or UDP, and that data is encapsulated in MPLS
   somewhere within the network, and then those MPLS packets are
   themselves encapsulated in UDP as described in this document.  That
   means that the decision points for the concerns and choices described
   in the sections that follow are at the point of encapsulation of MPLS
   in UDP, and at the time of deployment of the encapsulation function.
   While there are possibilities to apply back-pressure to applications,
   when there is tunneling within tunnels and a significant amount of
   multiplexing of flows within flows (as is the case with MPLS-in-UDP)
   these techniques are hard to apply and may have less immediate
   effect.

   Implementers are advised to note that widely deployable
   implementations have to provide the function set that is needed in
   each of the deployment scenarios discussed below.  That is, those
   implementations that only provide a subset of the functionality are
   not suitable for deployment in the full set of scenarios.

   The text in these sections is not intended to be, and should not be
   taken as, broader guidance for the issues of tunneling different
   protocols over UDP.

x.1.  Congestion Considerations

   End-to-end traffic flows may be multiplexed into MPLS LSPs, and those
   LSPs may be multiplexed into a single UDP tunnel.  These UDP tunnels
   appear as single flows in the core IP network over which the tunnel
   flows.  Thus, any congestion issues related to the core network and 
   caused by end-to-end traffic flows may be hard to report back to the
   head ends of the flows causing the congestion.

   The impact of congestion must be considered both in terms of the
   effect on the rest of the network of a UDP tunnel that is consuming
   excessive capacity, and in terms of the effect on the flows using the
   UDP tunnels in particular if packets are queued (causing delay or 
   jitter) or dropped.

   Various mechanisms exist to propagate congestion information to the
   source of flows either when congestion has occurred or when it is
   perceived to be imminent.  It should be noted that in the case of a
   tunnel (such as a UDP tunnel), the source of a flow is the head end
   of the tunnel.  That is, any congestion notification from the core
   network will be propagated to the head end of the tunnel, not to the
   original source of the traffic.  

   The head end of a UDP tunnel can take a number of actions when it is
   informed about congestion.  No comment is made here about which
   action is best or even appropriate, but section x.3 discusses these
   actions in the context of the different deployment scenarios.

   - Do nothing assuming that the burden of congestion will be carried 
     by other flows, or that the fact of congestion on the UDP tunnel
     will cause back-pressure in the payload flows.

   - Pass on the congestion information to the payload flows.  However,
     in this instance the payload of the UDP tunnel is MPLS flows, and
     the mechanisms for congestion notification in MPLS flows are
     lacking.

   - Throttle the data being placed onto the UDP tunnel by queuing or
     dropping packets from the payload flows.

   - Change the flows that are in a tunnel by putting some of them in a
     different tunnel.  This may have no effect on the congestion, but
     in some networks with ECMP may result in an improvement.

   - Completely fail one or more flows carried in the tunnel, or even
     fail the entire tunnel.  This mechanism is sometimes known as
     "circuit breaker".

x.2.  UDP Checksum Considerations

is checksum an issue
what can be done about it

- use it or not

x.3.  Deployment Scenarios

x.3.1.  MPLS-in-UDP over the Public Internet

   - Tunneling across the Internet
   The use of MPLS-in-UDP over the public Internet is NOT RECOMMENDED.

x.3.2. MPLS-in-UDP in Managed Networks

   - Tunneling over a provider network in a customer/provider
     relationship
   - Tunneling in a client/server relationship owned by a single
     operator

x.3.3. MPLS-in-UDP in Private Networks

   - Tunneling in a client/server relationship owned by a single
     operator
   - Tunneling within a "flat" network

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 22 Jul 2014 11:09:49 -0400

> take the pen (if no-one wants to, I will try to continue and complete this).

Adrian, thank you for sending this.

It's important (as we gather what seems to be an inexhaustible supply of 
foos to encapsulate with UDP), and David and Gorry were able to point to 
your e-mail during TSVWG this morning.

Spencer