Connect. Secure. Manage.
Cisco PFC and ECN Tuning
Tune Cisco priority flow control and congestion notification for your workloads, testing their impact rather than assuming lossless performance.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
Cisco PFC and ECN tuning deals with traffic when an Ethernet network gets busy. PFC and ECN do different jobs, and neither creates extra capacity. We test the supported network and its endpoints together for the actual workload. Changes are made in controlled steps, with records of the settings and the effect they had.
Workload-led design
Start with application, compute and storage dependencies rather than the switch model.
Clear failure domains
Understand which links, devices and sites can fail together.
Operational clarity
Make fabrics, external routing and management responsibilities supportable.
Start with the symptom and the traffic class
A tuning engagement should begin with a specific problem: reduced job throughput, sustained pause activity, queue drops or uneven performance during concurrent operations. We find the affected endpoints, traffic class and time period before considering changes to the settings. A healthy-looking average usage graph does not rule out short bursts that place pressure on a queue.
We also establish whether the workload is operating within the intended design. If extra jobs or endpoints have exceeded its capacity assumptions, changing thresholds may only move the bottleneck. The investigation distinguishes setup faults from a genuine shortage of forwarding or endpoint resources.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Verify markings and trust boundaries
PFC acts on priorities. So the network must classify the intended traffic consistently. We inspect endpoint markings, ingress policy, queue mappings and any changes made across routed or overlay paths. A mismatch can put RDMA traffic into the wrong queue or allow unrelated packets to consume resources reserved for it.
Trust should be deliberate. Accepting all markings from an uncontrolled interface can undermine the policy even when the switches are configured consistently. We document where classification originates and use representative traffic to confirm the operational result, rather than relying solely on a setup comparison.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Understand the platform’s buffering model
The available queues, buffer allocation and supported thresholds vary between Cisco platforms and software releases. We review the exact hardware guidance and the way the proposed features share resources. Values taken from another switch family may be inappropriate even if the setup syntax appears similar.
Cable distance, link speed and endpoint behaviour can influence the conditions a design must accommodate. We do not publish universal threshold values or assume that increasing every buffer allocation is beneficial. The aim is a supported setup with a clear explanation of the resources it uses and the trade-offs it creates.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Assess congestion feedback at the endpoint
ECN marking is useful only when the receiving transport and endpoint rollout respond as intended. We work with the platform team to confirm the relevant adapter, driver and congestion-control settings. Observing marks on the switch does not by itself establish that senders are reducing pressure effectively.
The investigation correlates marked traffic, queue occupancy, throughput and app timing. Where feedback is absent or ineffective, we identify the boundary at which the behaviour differs from the design. This prevents repeated network changes from obscuring an endpoint setup or software compatibility issue.
Control the consequences of pausing
PFC can protect chosen traffic from some congestion-related loss conditions, but pause propagation and prolonged pausing can affect service behaviour. We examine where pauses originate, how long they persist and whether other flows are unfairly delayed. The analysis includes the supported safeguards available on the chosen platform.
A goal of zero drops should not conceal unacceptable latency or stalled workloads. We agree which app measures matter and how to recognise a regression. If the network cannot meet those measures within its supported settings, the recommendation may involve topology, capacity or workload changes rather than further threshold adjustments.
Change one hypothesis at a time
We capture the baseline, setup and representative workload conditions before tuning. Each proposed change states the expected effect, the measurement used to assess it and the rollback action. Small, controlled experiments make the results easier to interpret than changing markings, queue mappings and endpoint settings simultaneously.
Tests need a suitable setup and approval from the affected service owners. We avoid experimenting with a live storage or compute fabric simply because an interface counter looks unusual. Where production testing is necessary, its duration, safety limits and recovery duties are agreed in advance.
Deliver a repeatable operating baseline
The final record includes the tested setup, endpoint prerequisites, observed behaviour and unresolved constraints. Monitoring thresholds should reflect this baseline and identify conditions that require investigation. Future software or workload changes should trigger a review rather than assuming the original settings remain optimal indefinitely.
MCI’s work can support Cisco RoCE network design or a focused performance incident. We provide an evidence-led tuning service, not a promise that PFC and ECN will compensate for every overload or guarantee a lossless fabric. The outcome is a defensible setup and a clear explanation of what it has actually been shown to support.
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.