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

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Adrian,

Thank you for producing this text and actively addressing all comments and review input on this document! Many thanks also because “soon” was very soon indeed!

Some of this text, however, seems pretty heavy-handed. Please find some comments inline.

—
Carlos Pignataro, [e-mail]

> On Feb 12, 2018, at 5:33 PM, Adrian Farrel <[e-mail]> wrote:
> 
> 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

Are these “control” packets? These are packets with a specific characteristic (not with a specific function), and according to the Abstract, “this document illustrates some of the functions that may be achieved”. It does not say “These are control packets …"

> and not intended to be sent frequently for any flow

Might be useful to define flow (by way of a pointer at least), since it’s not used in RFC 8300.

> , there is still a risk that they might flood the network.

Flood the whole 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

:s/will/may/g ?

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

:s/will/may/g ?

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

per-SFP instead of per-SFC?

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

I think “per-SFC” means “per-SFP”  throughout above. However, what is the mapping of applications? Not all nodes may have per-application visibility (or knowledge). 

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

From an operational standpoint what are the defaults for these proposed configuration knobs?

Another important consideration: if the protocol-none packet is for a specific function, what are the implications to that application or function leveraging this mechanism? For example, if, as mentioned above, this is used for OAM, rate-liming without visibility to the OAM rate limiting or function can result in actually more congestion with false-negatives, oscillations, instability, etc.

I strongly recommend some per-use implications, and a SHOULD understand implications before blindly rate-limiting.

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

This places an interesting requirement: it does not allow for incremental deployment. Not only protocol-none feature generating nodes need to be upgraded, but every node at once.

> Such rate limits SHOULD be application-aware, per SFC or interface,

This granularity seems beyond what might be possible. Per-SFC should be per-SFP. Not always there’s app-awareness. What’s an interface in this context?

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


Thanks again, Adrian!

Carlos.

>  
>  
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc