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

[Martin Stiemerling <[e-mail]>]

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


>
> Stewart.
>
> Sent from my iPad
>
>> On 5 Jan 2016, at 21:47, Martin Stiemerling <[e-mail]>
>> wrote:
>>
>> 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.
>>
>>
>>
>>
>> _______________________________________________ mpls mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/mpls