Re: [sfc] Proposal for congestion control in draft-farrel-sfc-convent

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Adrian,

this text looks really good to me. Thanks!

I only comment I have is that is would be even better if you could give some more concrete guidance what the rate should be limited to. I don’t know if that makes sense for the SFC use case but in RFC8085 the guidance would be: „... not sending on average more than one UDP datagram per RTT to a destination“.

Please update the draft, depending on the wg feedback of course, and I’ll clear my discuss.

Mirja

> Am 12.02.2018 um 23:33 schrieb Adrian Farrel <[e-mail]>:
> 
> Hi Mirja and Martin,
>  
> Here is a proposal to address Mirja’s Discuss. It is a new top-level section.
>  
> It is for discussion, so please tell me what it is missing and how we should work on it.
>  
> It makes sense (to me) for the WG to comment about this as well.
>  
> Thanks,
> Adrian
>  
> ====
> 6. Management and Congestion Control Considerations
>  
> The mechanisms described in this document allow SFC-aware nodes in an SFC network to generate additional packets.  While these packets are in the nature of in-band control packets and not intended to be sent frequently for any flow, there is still a risk that they might flood the network. For example, if an attempt is made to use this mechanism for “per-packet metadata” (Section 5.6) then this might double the number of packets in the network. Similarly, if this mechanism is used for a form of aliveness detection OAM that requires very frequent test messages, then the number of additional messages may be very high. Such additional messages risk causing congestion in the network.
>  
> The underlay network (that is the tunnels across the underlay between SFC nodes) will not distinguish between data-carrying packets and those packets with next protocol set to none. All packets will be treated the same and will need to fall within the capabilities of the underlay network to process and forward packets.
>  
> Nodes in the SFC overlay network will need to perform special processing on the additional packets according to their roles and according to the application for the metadata. For example, an SFF will likely only have to forward per-SFC metadata, while an SF will need to extract it and process it as it would if the metadata was carried in a packet with user data. On the other hand, metadata might also be used to cause actions at all nodes (see Sections 5.3, 5.4 and 5.5) and could increase the processing load.
>  
> In view of these potential issues, all implementations SHOULD implement rate limits on the generation of SFC packets with next protocol set to none. Furthermore, these rate limits SHOULD be configurable and applied per SFC and per application so that one application on one SFC does not encumber a different application on a different SFC. When an implementation finds that it is unable to generate or send a packet it SHOULD increment a counter that is accessible by the operator, and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
>  
> Additionally, an SFC node needs to protect itself against another node in the network not applying suitable rate limits. Therefore, implementations SHOULD apply incoming rate limits for SFC packets with next protocol set to none. Such rate limits SHOULD be application-aware, per SFC or interface, and SHOULD be configurable, but implementations MAY be more subtle if they are aware of internal processing loads and have access to queues/buffers. In any case, when an implementation drops a received packed because of these rate limits it SHOULD increment a counter that is accessible by the operator, and MAY raise an alert (although such alerts SHOULD, themselves, be rate limited).
> ====