Subject: [mpls] Martin Stiemerling's Discuss on draft-ietf-mpls-rfc6374-udp-return-path-04: (with DISCUSS)

From: "Martin Stiemerling" <[email-masked]>
Date: Tue, 05 Jan 2016 13:47:06 -0800

Martin Stiemerling has entered the following ballot position for
draft-ietf-mpls-rfc6374-udp-return-path-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-rfc6374-udp-return-path/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I am in favour of publishing this document, but I have two major points
that are not addressed in the document by now:

1) It is not clear for anybody what the expected size and sending
frequency of such MPLS-PLDM over IP/UDP responses are. This will
influence any measures an operator has to take in order to assure that
there is no congestion caused by these messages. I can understand that
this cannot be foreseen, but a few words considering this fact are
excellent to have in the document. 

2) This leads to my second point: the lack of any reference to RFC 5405
"Unicast UDP Usage Guidelines for Application Designers" and the content
out of this RFC that is applicable for this draft. There is no discussion
about this at all. Please note well that this is BCP 145. 

With regard to point 2): I can try to find some help from the transport
area, in case you need help.

---

From: Gmail <[email-masked]>
Date: Wed, 6 Jan 2016 17:10:40 +0000

Martin

It is  a fundamental tenet of MPLS is that the network is well managed with the operators paying significant attention to traffic planning, I therefore think that it is reasonable to assume that they would also pay adequate attention to their UDP management traffic.

Loss is so light in these networks that the interval between loss measurements needs to be long to see any loss at all, thus I would normally expect us to be talking packets per minute or packets per hour rather than packets per second, and this would be on links with GB+ capacity. Similarly it makes little sense to make delay measurements very frequently.

In both cases the amount of traffic will be minuscule compared to the IPFIX over UDP traffic that that many operators will already will running.

I thus fear that you raise the congestion daemon without proper regard to the practicalities of this type of application.

Stewart. 

Sent from my iPad

> On 5 Jan 2016, at 21:47, Martin Stiemerling <[email-masked]> wrote:
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 13 Jan 2016 10:39:56 +0100

Hi Steward,

Am 06.01.16 um 18:10 schrieb Gmail:
> Martin
>
> It is  a fundamental tenet of MPLS is that the network is well
> managed with the operators paying significant attention to traffic
> planning, I therefore think that it is reasonable to assume that they
> would also pay adequate attention to their UDP management traffic.
>
> Loss is so light in these networks that the interval between loss
> measurements needs to be long to see any loss at all, thus I would
> normally expect us to be talking packets per minute or packets per
> hour rather than packets per second, and this would be on links with
> GB+ capacity. Similarly it makes little sense to make delay
> measurements very frequently.
>
> In both cases the amount of traffic will be minuscule compared to the
> IPFIX over UDP traffic that that many operators will already will
> running.
>
> I thus fear that you raise the congestion daemon without proper
> regard to the practicalities of this type of application.

I fully understand that this type of protocol is used usually in a fully 
managed network. But congestion can also happen there, and congestion is 
by the way not a daemon, but a natural consequence of a best effort 
network even if it is managed

And even in fully managed networks traffic can accumulate at one point 
causing congestion.

I do not see the need to work through all details of RFC 5405, but I 
want to see text that reflects about using an not congestion controlled 
protocol and possible consequences and guidances for operators using this.
One way to handle this, to make operators aware of the need to monitor 
the rate of UDP traffic and that any excess of this rate is worth noting 
to the network operator.

By the way, your argument above about the managed environment would also 
make Section 5 superfluous, isn't it?

Thanks,

   Martin

>> When responding, please keep the subject line intact and reply to
>> all email addresses included in the To and CC lines. (Feel free to
>> cut this introductory paragraph, however.)
>>
>>
>> Please refer to
>> https://www.ietf.org/iesg/statement/discuss-criteria.html for more
>> information about IESG DISCUSS and COMMENT positions.
>>
>>
>> influence any measures an operator has to take in order to assure
>> that there is no congestion caused by these messages. I can
>> understand that this cannot be foreseen, but a few words
>> considering this fact are excellent to have in the document.
>>
>> 2) This leads to my second point: the lack of any reference to RFC
>> 5405 "Unicast UDP Usage Guidelines for Application Designers" and
>> the content out of this RFC that is applicable for this draft.
>> There is no discussion about this at all. Please note well that
>> this is BCP 145.
>>
>> With regard to point 2): I can try to find some help from the
>> transport area, in case you need help.
>>
>>
>>
>>
>> _______________________________________________ mpls mailing list
>> [email-masked] https://www.ietf.org/mailman/listinfo/mpls

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 21 Jan 2016 11:49:40 +0000

On 13/01/2016 09:39, Martin Stiemerling wrote:
> I fully understand that this type of protocol is used usually in a 
> fully managed network. But congestion can also happen there, and 
> congestion is by the way not a daemon, but a natural consequence of a 
> best effort network even if it is managed

Martin

If a basic monitoring protocol such as this, drives a network over the 
edge through congestion, then there is so much else wrong with that the 
network that it would be unable perform it primary mission. My concern 
is that by always highlighting congestion concerns, even when the risk 
is minor, you dilute the importance of the message when there is a real 
need for caution.

> And even in fully managed networks traffic can accumulate at one point 

Again, if this type of protocol pushes it over the edge, I would be 
concerned that there were much more significant issues with that network.

> want to see text that reflects about using an not congestion 
> controlled protocol and possible consequences and guidances for 
> operators using this.
> the rate of UDP traffic and that any excess of this rate is worth 
> noting to the network operator.
>
> By the way, your argument above about the managed environment would 
> also make Section 5 superfluous, isn't it?

I will willingly delete section 5 if that is the consensus of the IESG.

The following text inserted as a new section between section 4 and 5 
will hopefully address your congestion concerns.

5. Congestion Considerations

This protocol MUST be run in accordance the guidance provided in 
[RFC5405]. As advised in  section 3.2.1 of RFC5405, operators that wish 
to run this protocol at rates in excess of one packet per three seconds 
need to ensure that the MPLS path being monitored and any IP path that 
may be used to carry the response are provisioned such that there is a 
negligible chance of this protocol causing congestion. Additionally, if 
a significant number of response packets are lost, the querier MUST 
reduce the sending rate to a point where there is a negligible chance 
that this protocol is contributing to network congestion. The operator 
should also take precautions that response packets do not leak out of 
the network domain being used and cause congestion elsewhere. If a 
default IP address is configured by the equipment vendor, this MUST be 
an address known to contain the response packet within the responder, 
such as the IPv4 localhost address [RFC5735] or the IPv6 loopback 
address [RFC4291]. A responder receiving a query specifying this as a 
return  address, and not being configured to expect such a return 
address*, SHOULD notify the operator in a suitably rate limited manner.

Add refs to RFC5405 (normative), RFC 5735 (informational) and RFC 4291 
(informational)

*Not part of RFC text - this might occur if the operator wanted a data 
collector co-located on the responder, so it's better to specifically 
allow it than have confusion as to whether it is allowed or not.

- StewarT

---

From: Martin Stiemerling <[email-masked]>
Date: Sun, 31 Jan 2016 22:37:32 +0100

Hi Steward,

> allow it than have confusion as to whether it is allowed or not.

Perfectly! I will clear once there is the updated draft.

Thank you,

   Martin