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

From: "Eggert, Lars" <[email-masked]>
Date: Wed, 22 Jan 2014 17:55:23 +0000

Hi,

On 2014-1-22, at 18:29, Noel Chiappa <[email-masked]> wrote:
> Envision the following 4 (or more) scenarios for one Border Tunneling Routing
> (BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultimate
> source S (somewhere before BTR A) to destination D (somewhere after BTR B).
> 
> - Plain IP
> - Some existing encapsulation like GRE
> - A new, custom encapsulation
> - Encapsulation using UDP
> 
> What you seem to be claiming is that in case 4 we need to have congestion
> detection and response at the intermediate forwarding node BTR A - but it
> would not be required in cases 1-3? This makes no sense.

I'm not saying that. I'm saying that for every tunnel that can extend the reach of not-congestion-controlled traffic, e.g., some L2 traffic, over the wider Internet, we have a potential problem.

For plain IP as well as encapsulations that use IP protocol numbers that are different than UDP, TCP and I guess ICMP, that danger is somewhat mitigated, because such traffic typically dies at the next NAT or firewall (unless that has been specifically provisioned, which is then also OK). So there can be harm, but it will be limited to some segment of the network, hopefully the segment that the entity who performed the encapsulation manages.

UDP and TCP traverse most NATs and firewalls, if the directionality of the flow establishment is as expected by the middlebox ("inside" to "outside"). That means that UDP-encapsulated L2 traffic has a much wider reach - an Internet-wide reach. That's the fundamental difference to the other cases.

> Even better, suppose that BTR A implements _both_ one of the first three,
> _and_ UDP encapsulation. If its response to UDP congestion on the path to BTR
> B is to.... switch to a _different_ encapsulation for traffic to that
> intermediate forwarding node, one for which it's not required to detect and
> respond to congestion, did that really help?

It won't solve the problem, but these other encapsulations have more limited reach, and as such the potential for damage is lessened.

> Similarly, if people doing tunnels ditched UDP in favor of some other
> encapsulation (assuming they could find something that would get through as
> many filters as UDP does, would have the same load-spreading properties that
> UDP does, etc, etc - or maybe not, if that's the price they have to pay for
> being free of the grief they are getting because they are using UDP) - would
> that do anything at all for any potential congestion from their traffic? No,
> it would still be there, obviously.

Depends on the reach of that encapsulation. If it requires manual configuration of middleboxes to make it traverse (like GRE would), that danger is lessened. If it traversed such middleboxes by default, as UDP does, it has the same issues.

> Look, the current architectural model of the Internet for dealing with
> congestion is that the _application endpoints_ have to notice it, and slow
> down. Intermediate forwarding nodes don't have any particular responsibility
> other than to drop packets if they have too many.

Right. From the viewpoint of the Internet, the *encapsulator* is that application endpoint. That's what the whole concept of a tunnel is about.

> You are quite right that if we take some application that doesn't detect and
> respond to congestion (perhaps because it was written for a local environment,
> and some bright spark is tunnelling that L2 protocol over the Internet), that
> can cause problems - but that's because we are violating the Internet's
> architectural assumption on how/who/where congestion control is done.

Exactly. 

> I don't have any particularly brilliant suggestions on how to respond to
> situations in which applications don't detect and respond to congestion.
> Architecturally, if we are to keep to the existing congestion control scheme
> (endpoints are responsible), the responsibilty has to go back to the ultimate
> source of the traffic somehow...

No, it doesn't. That responsibility lies with the entity that injects that packet into the Internet, which is the encapsulator. For the rest of the Internet, the encapsulator is the sending application of the UDP traffic. Without the encapsulator, that traffic would not exist on the Internet.

> But saying that _intermediate forwarding nodes_ have to detect down-stream
> congestion, and respond, represents a fundamental change to the Internet's
> architecture for congestion control.

And here's the fallacy: UDP encapsulators are forwarding nodes *only* from the viewpoint of the final endpoints. From the viewpoint of the rest of the Internet, they are traffic *sources*, not *forwarders*. 

Lars

---

From: [email-masked] (Noel Chiappa)
Date: Wed, 22 Jan 2014 12:29:30 -0500 (EST)

> From: "Eggert, Lars" <[email-masked]>

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

I think people are looking at this from the wrong perspective, focusing in on
UDP and what its specs say, and not on the larger engineering picture.

- Plain IP

	Noel

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2014 13:15:13 -0800

>> would not be required in cases 1-3? This makes no sense.

FWIW, the whole point of using UDP is to leverage the Internet's ability 
to interpret the tunneled traffic as application data - to manage it 
according to port-based flow interpretation.

There's a cost associated with that privilege - the cost of needing to 
react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic 
congestion control; it does mean *reacting* to congestion in some way, 
over some timescale more than just ignoring things.

This should be expected of any tunneling system that encapsulates 
non-reactive flows - regardless of technology.

Joe

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 23 Jan 2014 13:27:16 -0800

Part of the point of using UDP is to make use of lowest common denominator
forwarding hardware in introducing entropy to protocols that lack it ( this
is particularly true of the GRE in UDP use case also under discussion
elsewhere).

The tunnel is not the source of the traffic.  The _source of the traffic_
is the source of the traffic.  The originating application who's traffic is
being tunneled should be responsible for congestion control, or lack there
of.  Are we advocating a return to intermediate congestion control (I like
X.25 as much as the next guy, but...).  This is a very stark change of
direction.

I think mandating congestion control  is not technically sound from either
a theoretical (violation of end to end principle, stacking of congestion
control algorithms leading to complex and potentially suboptimal results)
or economic perspective (as a very large backbone, we've been doing just
fine without intermediate congestion management thank you very much, and I
have 0 desire to pay for a cost prohibitive, unnecessary feature in
silicon.)

I get Lars comments regarding reach, to some limited extent.  Ultimately,
the implication seems to be that the protocols riding the L2 network will
have no form of congestion control and are fundamentally different than
protocols that would reside on a typical wan.  I have some serious doubts
about this, although I'm sure this is the case in some specialized
environments.  At any rate, it seems to me that a stern warning regarding
edge filtering on interdomain boundaries will be sufficient.

On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch <[email-masked]> wrote:

> congestion control; it does mean *reacting* to congestion in some way, over
> some timescale more than just ignoring things.
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2014 13:38:57 -0800

On 1/23/2014 1:27 PM, Edward Crabbe wrote:
> Part of the point of using UDP is to make use of lowest common
> denominator forwarding hardware in introducing entropy to protocols that
> lack it ( this is particularly true of the GRE in UDP use case also
> under discussion elsewhere).
>
> The tunnel is not the source of the traffic.  The _source of the
> traffic_ is the source of the traffic.

To the Internet, the tunnel encapusulator is the source of traffic. 
Tracing the data back further than that is a mirage at best - and 
irrelevant.

The tunnel head-end is responsible for the tunnel walking, talking, and 
quaking like a duck (host). When the tunnel head-end knows something 
about the ultimate origin of the traffic - whether real, imagined, or 
from Asgard - then it has done it's duty (e.g., that it's already 
congestion controlled).

But that head end is responsible, regardless of what it knows or 
doesn't. And when it doesn't know, the only way to be responsible is to 
put in its own reactivity.

> The originating application
> who's traffic is being tunneled should be responsible for congestion
> control, or lack there of.

Perhaps it should be, but that's an agreement between whomever 
implements/deploys the tunnel headend and whomever provides the 
originating traffic to them. The problem is that this isn't true for the 
typical use case for this kind of encapsulation.

I.e., if we were talking about MPLS traffic that already was reactive, 
we wouldn't be claiming the need for additional encapsulator mechanism. 
It's precisely because nothing is known about the MPLS traffic that the 
encapsulator needs to act.

 > Are we advocating a return to intermediate
> congestion control (I like X.25 as much as the next guy, but...).  This
> is a very stark change of direction.
>
> I think mandating congestion control  is not technically sound from
> either a theoretical (violation of end to end principle, stacking of
> congestion control algorithms leading to complex and potentially
> suboptimal results) or economic perspective (as a very large backbone,
> we've been doing just fine without intermediate congestion management
> thank you very much, and I have 0 desire to pay for a cost prohibitive,
> unnecessary feature in silicon.)

Write that up, and we'll see how it turns out in the IETF. However, 
right now, the IETF BCPs do require reactive congestion management of 
transport streams.

If you don't want/like that, then either don't use transport 
encapsulation, or change the BCPs.

> I get Lars comments regarding reach, to some limited extent.
>   Ultimately, the implication seems to be that the protocols riding the
> L2 network will have no form of congestion control and are fundamentally
> different than protocols that would reside on a typical wan.  I have
> some serious doubts about this, although I'm sure this is the case in
> some specialized environments.  At any rate, it seems to me that a stern
> warning regarding edge filtering on interdomain boundaries will be
> sufficient.

My concern may be slightly different that his. My concern is that you 
want the benefits of a UDP header, but don't like the responsibilities 
that come along with it.

Joe

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 23 Jan 2014 15:32:03 -0800

> Tracing the data back further than that is a mirage at best - and

The 'internet' cares about characteristics of reactivity to congestion.
 This is guaranteed by the /source of the traffic/ independent of any
intermediate node.

> quaking like a duck (host). When the tunnel head-end knows something about
> the ultimate origin of the traffic - whether real, imagined, or from Asgard
> - then it has done it's duty (e.g., that it's already congestion
> controlled).
>
> But that head end is responsible, regardless of what it knows or doesn't.
> And when it doesn't know, the only way to be responsible is to put in its
> own reactivity.

This is not fact; it's actually precisely the principle  we're currently
arguing about.  ;)

I would posit:

The tunnel doesn't have to know anything about congestion or performance
characteristics because the originating application must.  See GRE, MPLS,
many other tunnel types, including several existing within the IETF that
make use of an outer UDP header.

> implements/deploys the tunnel headend and whomever provides the originating
> traffic to them. The problem is that this isn't true for the typical use
> case for this kind of encapsulation.
>

How so?  As mentioned before, this is the same case as standard GRE/MPLS
etc.

>
> I.e., if we were talking about MPLS traffic that already was reactive, we
> wouldn't be claiming the need for additional encapsulator mechanism. It's
> precisely because nothing is known about the MPLS traffic that the

The MPLS traffic doesn't have to be reactive, it's the applications being
encapsulated / traversing a particular tunnel that are responsible for and
aware of path and congestion charateristics.  Because the MPLS head end
knows nothing about the /end to end application 'session'/ characteristics
it /shouldn't/ have anything to do with congestion management.

> Write that up, and we'll see how it turns out in the IETF. However, right
> now, the IETF BCPs do require reactive congestion management of transport
> streams.
>

Which part?  The end-to-end principle, or the aversion to congestion
control stacking?  These have been implicit in all tunneling protocols
produced by the IETF for the modern internet.

> encapsulation, or change the BCPs.

These BCPs are defined for an originating /application/.  In this case the
UDP header is simply a shim header applied to existing application traffic.
 The tunnel head does not introduce traffic independent of the originating
application.

> My concern may be slightly different that his. My concern is that you want
> the benefits of a UDP header, but don't like the responsibilities that come
> along with it.
>
> Joe
>
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2014 15:56:46 -0800

>   This is guaranteed by the /source of the traffic/ independent of any

Are you prepared to make that a requirement of this document, i.e., that 
the only MPLS traffic that can be UDP encapsulated is known to react to 
congestion?

How exactly can you know that?

>     The tunnel head-end is responsible for the tunnel walking, talking,
>     and quaking like a duck (host). When the tunnel head-end knows
>     something about the ultimate origin of the traffic - whether real,
>     imagined, or from Asgard - then it has done it's duty (e.g., that
>     it's already congestion controlled).
>
>     doesn't. And when it doesn't know, the only way to be responsible is
>     to put in its own reactivity.
>

Actually, it's a paraphrasing of Section 3.1.3 of RFC5405.

We can continue to debate it, but until it's been *changed* by a 
revision, it remains BCP.

> characteristics because the originating application must.

That works only if you know that fact about the originating application. 
However, there are plenty of applications whose traffic goes over MPLS 
that isn't congestion reactive or bandwidth-limited.

 > See GRE,
> MPLS, many other tunnel types,

This isn't an issue for all tunnels until they enter the Internet...

> including several existing within the
> IETF that make use of an outer UDP header.

Which are all already supposed to follow the recommendations of RFC5405. 
To the extent that they don't, they don't agree with that BCP.

I'm not saying such things never can or will exist, but I don't think 
the IETF should be self-contradictory. We already agreed as a group on 
such BCPs and other standards, and new standards-track docs need to 
follow them.

>     originating traffic to them. The problem is that this isn't true for
>     the typical use case for this kind of encapsulation.
>

It's putting MPLS inside UDP. That's a different case, and the reason 
RFC5405 applies.

>     I.e., if we were talking about MPLS traffic that already was
>     reactive, we wouldn't be claiming the need for additional
>     encapsulator mechanism. It's precisely because nothing is known
>     about the MPLS traffic that the encapsulator needs to act.
>
> The MPLS traffic doesn't have to be reactive, it's the applications
> being encapsulated / traversing a particular tunnel that are responsible
> for and aware of path and congestion charateristics.  Because the MPLS
> head end knows nothing about the /end to end application 'session'/
> characteristics it /shouldn't/ have anything to do with congestion
> management.

OK, so what you're saying is that "traffic using this encapsulation MUST 
be known to be congestion reactive". Put that in the doc and we'll 
debate whether we believe it.

But right now you're basically saying that because you think it's 
someone else's problem (the originating application), it isn't yours. 
The difficulty with that logic is that you (the tunnel headend) is 
responsible to ensure that this is true - either by *knowing* that the 
originating traffic is congestion reactive, or by putting in its own 
mechanism to ensure that this happens if the originating application isn't.

>     right now, the IETF BCPs do require reactive congestion management
>     of transport streams.
>

Sure, and that's reflected in RFC5405 already. However, please, PLEASE 
appreciate that NOBODY here is asking you to put in "congestion control 
stacking"; that happens when you run two dynamic, reactive control 
algorithms using the same timescale on top of each other.

Equally well-known in CC circles is that you CAN - and often *should* - 
stack different kinds of mechanisms at different layers with different 
timescales. E.g., that's why we have an AQM WG - because even when all 
the traffic is TCP, that's not quite enough inside the network. That's 
also why Lars was suggesting something coarse on a longer timescale - a 
circuit breaker - rather than AIMD on a RTT basis.

Keep in mind as well that the E2E argument says that you can't get an 
E2E service by composing the equivalent HBH one; it also says that HBH 
mechanisms can be required for efficiency. That's what we're talking 
about here - the efficiency impact of congestion, not the overall 
correctness of E2E control.

> These BCPs are defined for an originating /application/.

Yes, and I don't understand why you (and others) keep thinking it 
matters that there are layers of things behind the tunnel head end. It 
doesn't - unless you KNOW what those layers are, and can ensure that 
they behave as you expect.

> In this case
> the UDP header is simply a shim header applied to existing application
> traffic.

It's not "simply a shim" - if that's the case, use IP and we're done. No 
need for congestion control.

The reason congestion issues arise is because you're inserting a header 
****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO REACT TO****.

If you put in a UDP-like header that nobody in the Internet would 
interpret, this wouldn't be an issue.

But you simply cannot expect the Internet to treat you like 
"application" traffic if you won't enforce acting like that traffic too.

> The tunnel head does not introduce traffic independent of the
> originating application.

The Internet ****neither knows nor cares****.

To the Internet, the head-end is the source. Whatever data the head end 
puts inside the UDP packets *is application data* to the rest of the 
Internet.

Again, if you are saying that you know so much about the originating 
source that you know you don't need additional mechanism at the headend, 
say so - but then live by that requirement.

If *any* MPLS traffic could show up at the headend, then it becomes the 
headend's responsibility to do something.

---

Consider the following case:

	- video shows up inside the OS, destined for the network

	- software X bundles that video and sends it to go out

	- software Y puts that data into UDP packets to go
	to the Internet

So what's the "application" here? To the Internet, it's software Y -- 
the thing that puts the 'application' data into UDP packets. The 
previous steps are irrelevant - just as irrelevant as the singer your 
video camera is filming, as irrelevant as the sun that created the light 
that is reflected off the singer to your camera.

If software Y knows so much about the steps that lead to its input data 
that it knows it's congestion reactive, nothing more need be done.

If NOT (and that's the relevant corollary here), then it becomes 
software Y's responsibility to put in some reactivity.

Joe

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jan 2014 19:07:25 -0500

I don't want to get in the way of vehement discussion, but I thought we
were on the verge of finding an actual solution...

IMHO, that was a combination of an applicability statement, using SHOULD
for congestion control and checksum, and defining a longer-term OAM-based
approach (as Stewart Bryant suggested) to be able to verify that packet
corruption or excessive drops aren't happening.

Does that sound like an acceptable set?

Alia

On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch <[email-masked]> wrote:

> We can continue to debate it, but until it's been *changed* by a revision,
> it remains BCP.
>
>
>  I would posit:
>>
> However, there are plenty of applications whose traffic goes over MPLS that
> isn't congestion reactive or bandwidth-limited.
>
>
> > See GRE,
>
> I'm not saying such things never can or will exist, but I don't think the
> IETF should be self-contradictory. We already agreed as a group on such
> BCPs and other standards, and new standards-track docs need to follow them.
>
>
> be known to be congestion reactive". Put that in the doc and we'll debate
> whether we believe it.
>
> But right now you're basically saying that because you think it's someone
> else's problem (the originating application), it isn't yours. The
> difficulty with that logic is that you (the tunnel headend) is responsible
> to ensure that this is true - either by *knowing* that the originating
> traffic is congestion reactive, or by putting in its own mechanism to
> ensure that this happens if the originating application isn't.
>
>
> timescales. E.g., that's why we have an AQM WG - because even when all the
> traffic is TCP, that's not quite enough inside the network. That's also why
> Lars was suggesting something coarse on a longer timescale - a circuit
> breaker - rather than AIMD on a RTT basis.
>
> Keep in mind as well that the E2E argument says that you can't get an E2E
> service by composing the equivalent HBH one; it also says that HBH
> mechanisms can be required for efficiency. That's what we're talking about
> here - the efficiency impact of congestion, not the overall correctness of
> E2E control.
>
>
> Yes, and I don't understand why you (and others) keep thinking it matters
> that there are layers of things behind the tunnel head end. It doesn't -
> unless you KNOW what those layers are, and can ensure that they behave as
> you expect.
>
>
>  In this case
> But you simply cannot expect the Internet to treat you like "application"
> traffic if you won't enforce acting like that traffic too.
>
>
> So what's the "application" here? To the Internet, it's software Y -- the
> thing that puts the 'application' data into UDP packets. The previous steps
> are irrelevant - just as irrelevant as the singer your video camera is
> filming, as irrelevant as the sun that created the light that is reflected
> off the singer to your camera.
>
> If NOT (and that's the relevant corollary here), then it becomes software
> Y's responsibility to put in some reactivity.
>
> Joe
>

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 23 Jan 2014 16:08:24 -0800

I think there also needs to be a network boundary statement with
recommendations for filtering and usage in terms of intra vs interdomain
protocol usage.

---

From: Joe Touch <[email-masked]>
Date: Thu, 23 Jan 2014 16:10:22 -0800

Hi, Alia,

On 1/23/2014 4:07 PM, Alia Atlas wrote:
> for congestion control and checksum, and defining a longer-term
> OAM-based approach (as Stewart Bryant suggested) to be able to verify
> that packet corruption or excessive drops aren't happening.
>

It answers my concerns (I was concerned about the checksum issue too, 
though it seems to have petered out). I wasn't tracking whether there 
were other issues that this doesn't address that were raised, though.

Joe

> Alia
>
>
> On Thu, Jan 23, 2014 at 6:56 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>     Are you prepared to make that a requirement of this document, i.e.,
>     that the only MPLS traffic that can be UDP encapsulated is known to
>     react to congestion?
>
>     That works only if you know that fact about the originating
>     application. However, there are plenty of applications whose traffic
>     goes over MPLS that isn't congestion reactive or bandwidth-limited.
>
>
>      > See GRE,
>
>     Which are all already supposed to follow the recommendations of
>     RFC5405. To the extent that they don't, they don't agree with that BCP.
>
>     I'm not saying such things never can or will exist, but I don't
>     think the IETF should be self-contradictory. We already agreed as a
>     group on such BCPs and other standards, and new standards-track docs
>     need to follow them.
>
>
>     It's putting MPLS inside UDP. That's a different case, and the
>     reason RFC5405 applies.
>
>
>     OK, so what you're saying is that "traffic using this encapsulation
>     MUST be known to be congestion reactive". Put that in the doc and
>     we'll debate whether we believe it.
>
>     someone else's problem (the originating application), it isn't
>     yours. The difficulty with that logic is that you (the tunnel
>     headend) is responsible to ensure that this is true - either by
>     *knowing* that the originating traffic is congestion reactive, or by
>     putting in its own mechanism to ensure that this happens if the
>     originating application isn't.
>
>
>                  suboptimal results) or economic perspective (as a very
>         large
>                  backbone,
>     Sure, and that's reflected in RFC5405 already. However, please,
>     PLEASE appreciate that NOBODY here is asking you to put in
>     "congestion control stacking"; that happens when you run two
>     dynamic, reactive control algorithms using the same timescale on top
>     of each other.
>
>     Equally well-known in CC circles is that you CAN - and often
>     *should* - stack different kinds of mechanisms at different layers
>     with different timescales. E.g., that's why we have an AQM WG -
>     because even when all the traffic is TCP, that's not quite enough
>     inside the network. That's also why Lars was suggesting something
>     coarse on a longer timescale - a circuit breaker - rather than AIMD
>     on a RTT basis.
>
>     Keep in mind as well that the E2E argument says that you can't get
>     an E2E service by composing the equivalent HBH one; it also says
>     that HBH mechanisms can be required for efficiency. That's what
>     we're talking about here - the efficiency impact of congestion, not
>     the overall correctness of E2E control.
>
>
>     matters that there are layers of things behind the tunnel head end.
>     It doesn't - unless you KNOW what those layers are, and can ensure
>     that they behave as you expect.
>
>
>         In this case
>     It's not "simply a shim" - if that's the case, use IP and we're
>     done. No need for congestion control.
>
>     The reason congestion issues arise is because you're inserting a
>     header ****THAT YOU EXPECT PARTS OF THE INTERNET YOU TRAVERSE TO
>     REACT TO****.
>
>     To the Internet, the head-end is the source. Whatever data the head
>     end puts inside the UDP packets *is application data* to the rest of
>     the Internet.
>
>     source that you know you don't need additional mechanism at the
>     headend, say so - but then live by that requirement.
>
>     If *any* MPLS traffic could show up at the headend, then it becomes
>     the headend's responsibility to do something.
>
>     ---
>
>     So what's the "application" here? To the Internet, it's software Y
>     -- the thing that puts the 'application' data into UDP packets. The
>     previous steps are irrelevant - just as irrelevant as the singer
>     your video camera is filming, as irrelevant as the sun that created
>     the light that is reflected off the singer to your camera.
>
>     If software Y knows so much about the steps that lead to its input
>     data that it knows it's congestion reactive, nothing more need be done.
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 23 Jan 2014 19:22:13 -0500

> recommendations for filtering and usage in terms of intra vs interdomain

Agreed - I think that's part of describing how the applicability statement
can be enforced by a service provider.

Alia

>>> the IETF should be self-contradictory. We already agreed as a group on such
>>> someone else's problem (the originating application), it isn't yours. The
>>> doesn't - unless you KNOW what those layers are, and can ensure that they
>>> behave as you expect.
>>>
>>>
>>>  In this case
>>> the thing that puts the 'application' data into UDP packets. The previous
>>> steps are irrelevant - just as irrelevant as the singer your video camera
>>> is filming, as irrelevant as the sun that created the light that is
>>> reflected off the singer to your camera.
>>>

---

From: <[email-masked]>
Date: Fri, 24 Jan 2014 00:33:49 +0000

I wouldn't say the checksum issue has petered out - I've provided replacement paragraphs of text to Xiaohu which will hopefully resolve it.

Lloyd Wood
http://about.me/lloydwood
________________________________________
From: ietf [[email-masked]] On Behalf Of Joe Touch [[email-masked]]
Sent: 24 January 2014 00:10
To: Alia Atlas
Cc: [email-masked]; Edward Crabbe; Noel Chiappa; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Hi, Alia,

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 23 Jan 2014 21:31:47 -0500

Joe, while your argument is internally consistent, it is not consistent 
with history.  We have not demanded that tunnel entries behave fully 
like source hosts for any of the other myriad kinds of tunnels we have 
done over the years.

If we take your logic as stated, then the usage of IPSec over UDP would 
be required to apply congestion control unless it knew that all the 
content traffic was TCP.  Is that really your intent?

Yours,
Joel

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 23 Jan 2014 23:05:10 -0500

+1

Alia - Nice concise summary.  Thanks.

Curtis

In message <CAG4d1rf+wAJuD2GvYfm14bOoEvbhqq0azN5fOq35aPJDUvg=[email-masked]>
Alia Atlas writes:
> 
> I don't want to get in the way of vehement discussion, but I thought
> we were on the verge of finding an actual solution...
>  
> IMHO, that was a combination of an applicability statement, using
> SHOULD for congestion control and checksum, and defining a longer-term

---

From: Greg Daley <[email-masked]>
Date: Fri, 24 Jan 2014 03:38:44 +0000

Hi Joel, 

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Friday, 24 January 2014 1:32 PM
> To: Joe Touch; Edward Crabbe
> Cc: [email-masked]; Noel Chiappa; IETF discussion list
> Joe, while your argument is internally consistent, it is not consistent with
> history.  We have not demanded that tunnel entries behave fully like source
> hosts for any of the other myriad kinds of tunnels we have done over the years.

Actually, many of the tunnel protocols on the standards track have been either for upper-layer IP or Transport protocols or require congestion mitigation:

RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS each ask that tunnelled protocols support congestion mechanisms,
RFC5085 and 5586:  VCCV and BFD with VCCV define congestion considerations for pseudowire tunnels.
RFC 4719 updated by RFC 5641: Ethernet pseudowires over L2TP (a UDP encapsulated protocol)  permit packet loss indications to take down the active circuit. 
RFC 4454: ATM over L2TPv3 indicates that inelastic flows are stopped when congestion occurs.

They (ATM over L2TPv3 and Ethernet PW over L2TPv3) also require usage over a traffic engineered network.

RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to exceed the offered load of a typical TCP application on the same path.

For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just passing the buck to the upper layer protocol (which is OK, so long as the application protocol in UDP has congestion measures). For environments where this cannot be relied upon, additional protocol specification and applicability statements have previously been applied.

> If we take your logic as stated, then the usage of IPSec over UDP would be
> required to apply congestion control unless it knew that all the content traffic
> was TCP.  Is that really your intent?

Actually, one of the compelling use cases for running MPLS over UDP (or L2TPv3) would be to encapsulate the traffic in ESP in order to combat passive snooping.

For ESP I believe the implicit assumption (via the Traffic Selectors in IKE) was that the upper layer protocol is IP or in transport mode another protocol such as TCP, UDP etc.

Sincerely, 

Greg Daley
[email-masked]

---

From: John E Drake <[email-masked]>
Date: Fri, 24 Jan 2014 15:01:01 +0000

Ed,

I completely agree with your email, below.  As an aside, the L2 packets that Lars is worried about are transported over a pseudo-wire using MPLS, so the logical place to place congestion awareness is in the pseudo-wire endpoints.  I remember that this was in the PWE3's charter some time ago.

Yours Irrespectively,

John

From: mpls [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Thursday, January 23, 2014 1:27 PM
To: Joe Touch
Cc: [email-masked]; Eggert, Lars; Noel Chiappa; IETF discussion list
Subject: Re: [mpls] Last Call: <draft-ietf-mpls-in-udp-04.txt> (Encapsulating MPLS in UDP) to Proposed Standard

Part of the point of using UDP is to make use of lowest common denominator forwarding hardware in introducing entropy to protocols that lack it ( this is particularly true of the GRE in UDP use case also under discussion elsewhere).

The tunnel is not the source of the traffic.  The _source of the traffic_ is the source of the traffic.  The originating application who's traffic is being tunneled should be responsible for congestion control, or lack there of.  Are we advocating a return to intermediate congestion control (I like X.25 as much as the next guy, but...).  This is a very stark change of direction.

I think mandating congestion control  is not technically sound from either a theoretical (violation of end to end principle, stacking of congestion control algorithms leading to complex and potentially suboptimal results) or economic perspective (as a very large backbone, we've been doing just fine without intermediate congestion management thank you very much, and I have 0 desire to pay for a cost prohibitive, unnecessary feature in silicon.)

I get Lars comments regarding reach, to some limited extent.  Ultimately, the implication seems to be that the protocols riding the L2 network will have no form of congestion control and are fundamentally different than protocols that would reside on a typical wan.  I have some serious doubts about this, although I'm sure this is the case in some specialized environments.  At any rate, it seems to me that a stern warning regarding edge filtering on interdomain boundaries will be sufficient.

On Thu, Jan 23, 2014 at 1:15 PM, Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:

On 2014-1-22, at 18:29, Noel Chiappa <[email-masked]<mailto:[email-masked]>> wrote:
Envision the following 4 (or more) scenarios for one Border Tunneling Routing
(BTR), BTR A, to send packets to another BTR, BTR B, on the path from ultimate
source S (somewhere before BTR A) to destination D (somewhere after BTR B).

- Plain IP

FWIW, the whole point of using UDP is to leverage the Internet's ability to interpret the tunneled traffic as application data - to manage it according to port-based flow interpretation.

There's a cost associated with that privilege - the cost of needing to react to congestion. That doesn't require 1-RTT, TCP-friendly dynamic congestion control; it does mean *reacting* to congestion in some way, over some timescale more than just ignoring things.

This should be expected of any tunneling system that encapsulates non-reactive flows - regardless of technology.

Joe

_______________________________________________
mpls mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mpls

---

From: Scott Brim <[email-masked]>
Date: Fri, 24 Jan 2014 10:47:01 -0500

-05 version is out.

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 24 Jan 2014 18:04:50 +0000

On 24/01/2014 15:01, John E Drake wrote:
>
> Ed,
>
> I completely agree with your email, below.  As an aside, the L2 
> packets that Lars is worried about are transported over a pseudo-wire 
> using MPLS, so the logical place to place congestion awareness is in 
> the pseudo-wire endpoints.  I remember that this was in the PWE3's 
> charter some time ago.
>
> Yours Irrespectively,
>
> John
>
The charter says:

Whilst a service provider may traffic engineer their network
in such a way that PW traffic will not cause significant
congestion, a PW deployed by an end-user may cause
congestion of the underlying PSN. Suitable congestion
avoidance mechanisms are therefore needed to protect the
Internet from the unconstrained deployment of PWs. Congestion
avoidance may be more difficult with P2MP pseudowires than
P2P pseudowires. The WG will consider both cases.

https://datatracker.ietf.org/doc/draft-stein-pwe3-congcons/
has expired, but if you are interested in working on the subject
I am sure the authors would be delighted to talk to you.

Stewart

---

From: Joe Touch <[email-masked]>
Date: Fri, 24 Jan 2014 10:50:28 -0800

On 1/23/2014 6:31 PM, Joel M. Halpern wrote:
> with history.

That's also why we're not exchanging email over X.25. We learn and move on.

However, the fact that tunnel heads ought to act like hosts is an issue 
I've been raising in the IETF for over 15 years, and was the primary 
reason why I argued for transport mode support in routers for tunneling 
(see RFC 3884).

> We have not demanded that tunnel entries behave fully

That has been a continual mistake, one that a group was formed in 2005 
to address, which resulted in an INTAREA document on this:

http://tools.ietf.org/html/draft-touch-intarea-tunnels-01

That doc has been fallow for a while largely because the problem and its 
complexity hasn't been fully appreciated. We're hoping to correct that 
and revive it, FWIW.

> content traffic was TCP.  Is that really your intent?

Yes, and that's already what RFC 5405 says. The fact that IPsec-UDP 
encap doesn't address this is because RFC 3948 predates RFC 5405.

This document (mpls-in-udp) does not, however.

Joe

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 24 Jan 2014 16:13:17 -0600

> Does that sound like an acceptable set?

Alia, I certainly hope so (speaking as an individual), and I appreciate 
you conjuring up the specter of an applicability statement (speaking as 
TSV AD).

I expect to find that helpful.

Spencer

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 25 Jan 2014 15:47:48 -0500

In message <[email-masked]>
Greg Daley writes:
 
> Actually, many of the tunnel protocols on the standards track have
> been either for upper-layer IP or Transport protocols or require
> congestion mitigation:
>  
>    RFC 4448 for EoMPLS, and 5994 for Ethernet pseudowires over MPLS
>    each ask that tunnelled protocols support congestion mechanisms,
>    RFC5085 and 5586: VCCV and BFD with VCCV define congestion
>    considerations for pseudowire tunnels.  RFC 4719 updated by RFC
>    5641: Ethernet pseudowires over L2TP (a UDP encapsulated protocol)
>    permit packet loss indications to take down the active circuit.
> RFC 4817 MPLS over L2TPv3 requires non-IP upper layer protocols not to
> exceed the offered load of a typical TCP application on the same path.
>  
> For those protocols which have IP, UDP, TCP, SCCP or DCCP this is just
> passing the buck to the upper layer protocol (which is OK, so long as
> the application protocol in UDP has congestion measures). For
> environments where this cannot be relied upon, additional protocol
> specification and applicability statements have previously been
> applied.
>  
> > required to apply congestion control unless it knew that all the
> Actually, one of the compelling use cases for running MPLS over UDP
> (or L2TPv3) would be to encapsulate the traffic in ESP in order to
> combat passive snooping.
>  
> For ESP I believe the implicit assumption (via the Traffic Selectors
> in IKE) was that the upper layer protocol is IP or in transport mode
> another protocol such as TCP, UDP etc.
>  
> Sincerely, 
>  
> Greg Daley
> [email-masked]

Reality check time.

To get the PW over MPLS drafts past the TSV AD there is a SHOULD
regarding congestion control.

AFAIK: No service providers ask for it.  No one implements it.  If
they did implement it no one would deploy it.

PW over MPLS is generally carrying relatively low volumes of high
priority traffic.  The TC bits (MPLS flavor of Diffserv DSCP) are used
to enforce the higher priority.  If congestion occurs other traffic on
that infrastructure (typically plain old Internet) sees loss.  That is
intended.  This is the reality of how PW over MPLS is deployed.

Anyone who knows of implementation or deployment of congestion control
for PW over MPLS can correct me.

I don't know about the "over GRE" or "over L2TP" tunneling.

Curtis

---

From: Mark Tinka <[email-masked]>
Date: Mon, 27 Jan 2014 21:29:54 +0200

On Saturday, January 25, 2014 10:47:48 PM Curtis Villamizar 
wrote:

> Reality check time.
> 
> To get the PW over MPLS drafts past the TSV AD there is a
> SHOULD regarding congestion control.
> 
> AFAIK: No service providers ask for it.  No one
> implements it.  If they did implement it no one would
> deploy it.
> 
> PW over MPLS is generally carrying relatively low volumes
> of high priority traffic.  The TC bits (MPLS flavor of
> Diffserv DSCP) are used to enforce the higher priority. 
> If congestion occurs other traffic on that
> infrastructure (typically plain old Internet) sees loss.
>  That is intended.  This is the reality of how PW over
> MPLS is deployed.
> 
> Anyone who knows of implementation or deployment of
> congestion control for PW over MPLS can correct me.

And this is what I mentioned several weeks ago. As 
operators, we police traffic on ingress and egress (some 
operators shape on egress, but the result is the same), and 
this is how we control admission to the network.

I have never used intrinsic congestion mechanisms in 
protocols (outside of lab fun-time when I'm really bored), 
and don't know anyone that has either. Of course, the risk 
is that router/switch vendors have all sorts of 
implementation as regards policing/shaping; but I can say 
that in the past 7x years or so (and especially in the past 
year for switches), this is reasonably mature, and no vendor 
worth their salt is shipping product that can't police or 
shape properly.

Just one point to make, not all traffic being carried over 
MPLS is "high priority". Some of it really isn't, and is 
treated on a best-effort basis. But, this is all specific to 
operators and their customers. General traffic admission 
rules still apply all the same.

Personally, if there was congestion mechanisms proposed as 
part of the MPLS-in-UDP spec., I would never run them as an 
operator. I'd rely on policing at the edge, as usual.

Cheers,

Mark.

---

From: Greg Daley <[email-masked]>
Date: Mon, 27 Jan 2014 22:18:08 +0000

Hi Curtis, 

> -----Original Message-----
[my post chopped]
> 
> 
> Reality check time.
> 
> To get the PW over MPLS drafts past the TSV AD there is a SHOULD regarding
> congestion control.
> 
> AFAIK: No service providers ask for it.  No one implements it.  If they did
> implement it no one would deploy it.
> 
> PW over MPLS is generally carrying relatively low volumes of high priority
> traffic.  The TC bits (MPLS flavor of Diffserv DSCP) are used to enforce the
> higher priority.  If congestion occurs other traffic on that infrastructure
> (typically plain old Internet) sees loss.  That is intended.  This is the reality of
> how PW over MPLS is deployed.
> 
> Anyone who knows of implementation or deployment of congestion control for
> PW over MPLS can correct me.
> 

Essentially, my point is that with traditional carriage environments there is an underlying medium which it may be possible to traffic engineer.
The value of a SHOULD is that it isn't necessary to there is a valid reason not to follow it (i.e. you control the medium and/or the ingress traffic flows and the traffic remains private).  The onus remains on the implementer and deployer not to mess up the Internet.

I think that similar guidance may be applicable in this case (as in GRE and L2TP encapsulations), where the next label switch could be across paths shared with other Internet traffic that has congestion avoidance, mitigation or control.

Sincerely, 

Greg Daley