I am unable to throttle the network by submitting my UDP packets among such links because I worry about packet drops and message losses.
At first blush, this sounds more like a design problem with the application, not the network:
- Networks are not reliable.
- UDP was never intended to transport messages reliably without adding application layer loss detection and retransmission.
If the application requires reliable messaging, many people use TCP (for unicast endpoints) or TIBCO RV (multicast endpoints). The devil is always in the details and there is no one size fits all solution.
Is there any way to detect instantly and repeatedly the available bandwidth between two data centers, So that I could throttle it with my packets?
You are essentially asking for what is traditionally called QoS.
Once you build rules to classify and prioritize your traffic, you can use QoS disciplines such as CBWFQ and LLQ to prioritize your most important traffic classes in the face of congestion (i.e low available bandwidth).
Alternatively you can use QoS to shape certain traffic classes to an average rate.
In general, UDP traffic classes are considered more loss sensitive than TCP classes. There are always exceptions to this rule of course; for instance TIBCO RV is commonly based on UDP multicast, but TIBCO includes sequence numbers to detect the need for retransmission. Depending on the applications, you may or may not need to prioritize UDP TIBCO classes over other TCP traffic.
I didn't find how to detect the available bandwidth.
It depends on the specific type of QoS, but in general:
- QoS classes monitor the average utilization within the traffic class
- QoS watches the interface queues for congestion and only prioritizes when the interface has a non-zero queue size (i.e. congestion).
This answer illustrates one kind of QoS configuration.
Final notes:
