https://github.com/prometheus/snmp_exporter

TCP Congestion Handling

Congestion by definition means intermediate devices – routers in this case – are overloaded. Meaning that TCP segments would not be delivered as fast as possible or they can be even dropped – which leads to retransmission.

Now, let’s suppose congestion dramatically increased on the internetwork, and there was no mechanism in place to handle congestion. Segments would be delayed or dropped, which would cause them to time out and be retransmitted. This would increase the amount of traffic on the internetwork between client/server. Furthermore, there might be thousands of TCP connections behaving similarly. Each would keep retransmitting more and more segments, increasing congestion further. Performance of the entire internetwork would decrease dramatically, resulting in a condition called congestion collapse.

Now TCP uses a number of mechanisms to achieve high performance and avoid congestion collapse. These mechanisms control the rate of data entering the network, keeping the data flow below a rate that would trigger the collapse. They also yield an approximately max-min fair allocation between flows.

Acknowledgments for data sent, or lack of acknowledgments, are used by senders to infer network conditions between TCP sender and receiver. Coupled with timers, TCP senders and receivers can alter the behavior of the flow of data. This is more generally referred to as congestion control and/or congestion avoidance.

Modern implementations of TCP contain 3 intertwined algorithms:

• Slow Start
• Congestion Avoidance
• Fast Retransmit
• Fast Recovery

(NOTE: The book states these mechanisms to RFC 2001, but it has evolved way more than that and now these mechanisms are stated in RFC 5681, which obsoletes RFC 2581 and which in turn obsoleted RFC 2001)

TCP Congestion Window

Is one of the factors that determine the number of bytes that can be outstanding at any given time. The congestion window is maintained by the sender.

The congestion window is a  means of stopping a link between the sender and the receiver from getting overloaded with too much traffic. It is calculated by estimating how much congestion there is between the two places.

When a connection is set up, the congestion window, a value maintained independently at each host, is set to a small multiple of the maximum segment size (MSS) allowed for that connection. Further variance in the congestion window is dictated by an Additive Increase/Multiplicative Decrease approach (I believe this was the case before Slow-Start which follows a more multiplicative increase).

This means that is all segments are received and the acknowledgments reach the sender on time, some constant is added to the window size. The window keeps growing exponentially until a timeout occurs or the receiver reaches its limit (a threshold value “ssthresh”). After this, the congestion window increases linearly at the rate of 1/congestion-window on each new acknowledgment received.

On timeout:

1. Congestion Window is reset to 1 MSS (not sure if is a complete MSS or just the initial fraction said before)
2. “ssthresh” is set to half the congestion widow size before packet loss started
3. “slow start” is initiated.

An administrator may adjust the maximum window size limit, or adjust the constant added during additive increase, as part of TCP tuning.

The flow of data over a TCP connection is also controlled by the use of the TCP receive window. By comparing its own congestion window with the receive window of the receiver, a sender can determine how much data it may send at any given time.

Slow Start (RFC 5681)

Is part of the congestion control strategy used in TCP – it is used in conjunction with other algorithms. It is also known as the exponential growth phase.

Slow-start begins initially with a congestion window size (cwnd) of 1, 2 or 10. The value of the congestion window (CWND) will be increased with each acknowledgment (ACK) received, effectively doubling the window size each round trip time (“although is not exactly exponential because the receiver may delay its ACKs, typically sending one ACK every two segments that it receives”). The transmission rate will be increased with slow-start algorithm until either a loss is detected, or the receiver’s advertised window (rwnd or RCV.WND) is the limiting factor, or the slow-start threshold (ssthresh) is reached. If a loss event occurs, TCP assumes that it is due to network congestion and takes steps to reduce the offered load on the network. These measurements depend on the used TCP congestion avoidance algorithm. Once ssthresh is reached, TCP changes from slow-start algorithm to the linear growth (congestion avoidance) algorithm. At this point the window is increased by 1 segment for each RTT.

Although the strategy is referred to as “Slow-Start”, its congestion window growth is quite aggressive, more aggressive than the congestion avoidance phase. Before slow-start was introduced in TCP, the initial pre-congestion avoidance phase was even faster. (To do more digging- I think initially it was a linear approach – what we used to call diente de sierra – and was a much slower approach to fill the link capacity with data)

The behavior upon packet loss depends on the TCP congestion avoidance algorithm that is used:

TCP Tahoe: In here, when a loss occurs, fast retransmit is sent, half of the current CWND is saved as a slow start threshold (ssthresh) and slow start begins again from its initial CWND. Once the CWND reaches the ssthresh, TCP changes to congestion avoidance algorithm where each new ACK increases the CWND by: ss + (ss/cwnd)

This results in a linear increase of the CWND.

TCP Reno: This implements an algorithm called fast recovery. A fast retransmit is sent, half of the current CWND is saved as ssthresh and as a new CWND, thus skipping slow-start and going directly to congestion avoidance algorithm

Transmission Control Protocol (TCP) uses a network congestion-avoidance algorithm that includes various aspects of an additive increase/multiplicative decrease (AIMD) scheme, with other schemes such as slow-start and congestion window to achieve congestion avoidance. The TCP congestion-avoidance algorithm is the primary basis for congestion control in the Internet.[1][2][3][4] Per the end-to-end principle, congestion control is largely a function of internet hosts, not the network itself. There are several variations and versions of the algorithm implemented in protocol stacks of operating systems of computers that connect to the Internet.

From <https://en.wikipedia.org/wiki/TCP_congestion_control>

What happens if we start moving hidden neuron layers (and neurons) from the initial Circle Data set at http://playground.tensorflow.org how many of those things we need to learn from current data set.

a simple perceptron, with only  4 neurons will have a great EPOCH

however 2 Neurons, will just not cut it with the offered data sets and Activation

check out Epoch using reLU

We are proud to present our new services

we offer:

Shared Web Hosting
VPS and Cloud
Dedicated Enterprise Server
Dedicated Web Host
Dedicates Storage
Game Servers

Build your Dream web site today using this promo code PROMO1M for a test drive!

Internet businesses, especially those which enable VOIP, e-commerce or cloud services, require IP redundancy. For them, network performance is crucial as it is directly connected to their quality of service. Any routing anomaly causing downtime or outages results in financial loss and might severely affect provider’s reputation. Deploying redundant IP connectivity is one of the most frequent solutions to minimize downtime, and this post will screen the most important steps in setting up redundancy for an IP network.

A redundant network is one connected to multiple internet providers. Such networks are commonly called multihomed. The Border Gateway Protocol (BGP) is used to connect to transit providers via eBGP sessions. The protocol is able to asses all the available routes, and find the shortest path to an end-user. Eventually, traffic is routed through the shortest available paths to achieve maximum performance.

Prepare your BGP Network:

BGP is quite similar to the Routing Information Protocol (RIP); however, instead of choosing the shortest path based on router hops, it relies on the shortest path among Autonomous Systems (AS). Autonomous System Numbers are associated with the BGP routing domains and are identified by an AS Number (ASN), provided by a Regional Internet Registry (RIR).

As you get to understand the BGP basics, configuring a multihomed network becomes simple. As soon as your network’s internet connections are up and running, you can follow these common steps to achieve BGP multihoming:

1. Get your own ASN. You can acquire one from your Regional Internet Registry, and identify your network on the internet, as a separate authority, running its own policies.
2. Purchase some IP address space from your RIR.
3. When using a static route to link with your provider, the network is single-homed (using one internet connection) and the internet provider is not sending any BGP routes to your network. In order to multihome, you must ask the internet provider to announce BGP routes towards your AS. Keep in mind, your ASN and the remote router’s neighbor address will be required by your internet provider. The static route can be removed as soon as you get the internet provider’s BGP routes in your routing table. As soon as you have all these in place, you can start advertising your network via BGP.
4. Once you are multihomed on a single route, add a link to an alternative internet provider, and ask it to advertise BGP routes towards your AS. The second internet provider will also require your ASN and the remote router’s neighbor address, so have them ready.

As soon as you have followed these steps, routes from each of your internet providers will appear within your edge router’s BGP table. According to BGP’s algorithm, routes having the shortest AS path towards a destination will be used to send the traffic through.

If one of your Internet providers goes down, the BGP session that enables connectivity with that provider will be reset and all of the advertised routes, originating from the offline provider shall be withdrawn from your routing table. Eventually, better alternative routes shall be selected from routes announced by the alternative internet provider.

Given to the BGP’s algorithm, all of your traffic might be sent out towards a particular provider, since it is the best one to route through. If the amount of traffic exceeds the internet provider’s link capacity, you might need to perform some tuning, to balance the traffic among your internet provider’s links. This task might be quite hard to accomplish, since BGP alone does not imply load balancing. As an alternative, you could use specific hardware or some route optimization​ solutions such as Noction’s Intelligent Routing Platform (IRP), to optimize BGP decision-making

BGP Usage and considerations:

When using BGP, there are several things to keep in mind:
e- Since BGP advertises network fluctuations to routers outside your AS, you must maintain your network to be as stable as possible.
– Advertise only a specific set of prefixes you own. Other networks might suffer service loss if you are advertising prefixes other than yours.
– Plan your architecture before engaging in BGP routing. Your network needs to be configured according to several BGP aspects in meeting multihoming requirements.
– Choose your edge routers. The Internet’s BGP tables involve huge amounts of data, especially with multihoming in place. Therefore, your edge routers must have enough memory to store and process all those routing tables.

While BGP alone can empower your network to deliver fair performance, it is still not enough when delivering performance sensitive applications, such as VOIP or e-commerce. Under some circumstances, the shortest path BGP selects, could be congested or affected by other network anomalies. However, traffic gets re-routed from from the shortest path only when it is the destination is completely unreachable. As a result, an end user might experience service delivery issues, since traffic is routed through a reachable, yet underperforming internet path.

To avoid such scenarios, BGP tuning must be performed at a network’s edge, which involves manipulating various BGP attributes to spot the issues and re-route specific prefixes, from those underperforming paths to alternative routes with better performance metrics. Best practices, recommend deployment of intelligent routing systems like Noction IRP, which can address most of your BGP challenges in a multihomed environment.

As soon as you have a redundant BGP network which is empowered by automation, you are ready to meet your customer’s demand for 100% uptime and outstanding network performance.

When carrying them on the SIP Network you could probably see the following methods of conveying these tones across:

1.- Inband:

DTMF are sent using the same RTP stream  as the media is using, and can be heard by carries in a session. Compression Codecs such as G.729 and G.723 may make tones unintelligible so it really works on better codecs like G.711

http://quequero.org/DTMF_decoding#DTMF_decoding_a_naive_approach

2.- RCF 2833:

(config)#dial-peer voice 100 voip

(config-dial-peer)#dtmf-relay ?

…

rtp-nte RTP Named Telephone Event RFC 2833

this is an out of band method that takes DTMF out of the RTP Stream, this means that the DTMF codes works even if the voice stream is compressed. This packets travelling out of band of RTP, hold events that can be understood by UA and regenerated, DTMF-related named events within the  telephone-event payload format.  http://www.ietf.org/rfc/rfc2833.txt

(config-dial-peer)#voice-class sip dtmf-relay force rtp-nte

A hidden command that forces the  “voice-class sip dtmf-relay force rtp-nte” DTMF relay negotiation to rtp-nte and It’s only necessary if the other side doesn’t advertise rtp-nte.

output from deb ccsip media –

000373: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Media/sipSPIUpdCallWithSdpInfo:
Stream type             : voice+dtmf
Media line              : 1
State                   : STREAM_ADDING (2)
Callid                  : -1
Negotiated Codec        : g711ulaw, bytes :160
Nego. Codec payload     : 0 (tx), 0 (rx)
Negotiated DTMF relay   : rtp-nte
Negotiated NTE payload  : 101 (tx), 101 (rx)
Negotiated CN payload   : 0
Media Srce Addr/Port    : 10.0.1.5:0
Media Dest Addr/Port    : 192.168.21.31:20424
000374: Dec  4 02:11:45.727: //55/18EBD6C48068/SIP/Info/sipSPIHandleInviteMedia:
Negotiated Codec       : g711ulaw, bytes :160
Preferred Codec        : g711ulaw, bytes :160
Preferred  DTMF relay 1 : 6
Preferred  DTMF relay 2 : 0
Negotiated DTMF relay   : 6
Preferred and Negotiated NTE payloads: 101 101
Preferred and Negotiated NSE payloads: 100 100
Preferred and Negotiated Modem Relay: 0 0
Preferred and Negotiated Modem Relay GwXid: 1 0

output from debug voip rtp session named-event will show digit 5 sent in 7 packets –

Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 00 00  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:04 01 90  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>
Feb 06 10:03:00.910:          Pt:101    Evt:5       Pkt:84 03 20  <Snd>>>

The first packet says that it is the start of a new NTE digit because it does not have the endbit set .

The second and third packets are repeats of the first packet for redundancy.

The fourth packet is a refresh packet with a duration of 50ms (0x0190 = 400 samples * 1sec / 8000 samples).

The fifth packet is the endbit packet (84) with a duration of 100ms (0x0320 = 800 samples * 1sec / 8000 samples).

The sixth and seventh packets are redundant packets for packet five.

in this RFC more events are defined, like for example: Fax related tones, Standard subscriber and Country Specific line tones and Trunk Events

This http://www.rfc-editor.org/rfc/rfc4733.txt supersedes RFC  2833, since  devices do not have to support every tone and event there is, they just simply advertise what they DO support when setting up a a connection

3.- SIP INFO: http://www.faqs.org/rfcs/rfc2976.html

This method is used to carry session control information along the SIP Signaling path during an existing session. SIP info can carry the digits you type without changing the characteristics of the SIP Session.

(config)#dial-peer voice 100 voip
(config-dial-peer)#session proto sip
(config-dial-peer)#dtmf-relay ?
cisco-rtp          Cisco Proprietary RTP
h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
h245-signal        DTMF Relay via H245 Signal IE
rtp-nte            RTP Named Telephone Event RFC 2833
sip-kpml           DTMF Relay via KPML over SIP SUBCRIBE/NOTIFY
sip-notify         DTMF Relay via SIP NOTIFY messages

you can not configure Cisco SIP-INFO to generate requests for DTMF tones, since this method is Considered Harmful based on http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00

The SIP INFO Method for DTMF Tone Generation feature is always enabled, and is invoked when a SIP INFO message is received with DTMF relay content. This feature is related to the SIP NOTIFY-Basec Out-of-Band DTMF Relay Support feature, which provides the ability for an application to be notified about DTMF events using SIP NOTIFY messages. Together, the two features provide a mechanism to both send and receive DTMF digits along the signaling path.

SDP is intended to be used for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.

http://www.ietf.org/rfc/rfc2327.txt

v=  (protocol version)
o=  (owner/creator and session identifier).
s=  (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information – not required if included in all media)
b=* (bandwidth information)
One or more time descriptions (see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions (see below)

Time description
t=  (time the session is active)
r=* (zero or more repeat times)

Media description
m=  (media name and transport address)
i=* (media title)
c=* (connection information – optional if included at session-level)
b=* (bandwidth information)
k=* (encryption key)
a=* (zero or more media attribute lines)

SAMPLE :

Sent:
INVITE sip:2911111@208.0.0.5:5060 SIP/2.0
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C
Remote-Party-ID: "NWN" ;party=calling;screen=no;privacy=off
From: "NWN" ;tag=27EFF0FC-2073
To:
Date: Wed, 03 Feb 2010 16:46:25 GMT
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 2044219673-270143967-2355415967-914914154
User-Agent: Cisco-SIPGateway/IOS-12.x
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, REGISTER
CSeq: 101 INVITE
Max-Forwards: 70in
Timestamp: 1265215585
Contact:
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 240

!SDP HEADER HERE

v=0
o=CiscoSystemsSIP-GW-UserAgent 6135 7812 IN IP4 65.0.0.57
s=SIP Call
c=IN IP4 65.0.0.57
t=0 0
m=audio 19344 RTP/AVP 0 100
c=IN IP4 65.0.0.57
a=rtpmap:0 PCMU/8000
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=ptime:20

*Feb  3 16:46:25.661: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C;received=65.0.0.57
From: "NWN" ;tag=27EFF0FC-2073
To:
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0

*Feb  3 16:46:26.693: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 65.0.0.57:5060;branch=z9hG4bKB287C;received=65.0.0.57
From: "NWN" ;tag=27EFF0FC-2073
To: ;tag=as76f79303
Call-ID: 8088F61B-101A11DF-8C6ACB9F-36887B6A@65.0.0.57
CSeq: 101 INVITE
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Type: application/sdp
Content-Length: 180

v=0
o=root 24622 24622 IN IP4 208.0.0.5
s=session
c=IN IP4 208.0.0.5
t=0 0
m=audio 12778 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

Now based on http://www.ietf.org/rfc/rfc3551.txt  & http://www.ietf.org/rfc/rfc4317.txt we can conclude, that audio is going to be encoded in PCMU as negotiated

As a side note, the UAS is not negotiating fmtp:100 192-194,

a=fmtp:<format> <format specific parameters>
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP doesn’t have
to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given
unchanged to the media tool that will use this format.

bringing possible issues with DTMF Tones (in-band or out-band) – Where  In-band relates to the RTP media stream, while out-of-band relates to the signaling path.

o=<username> <session id> <version> <network type> <address type>
<address>

=============================================================
o=CiscoSystemsSIP-GW-UserAgent 6135 7812 IN IP4 65.0.0.57
=============================================================

<network type> is a text string giving the type of network.
Initially “IN” is defined to have the meaning “Internet”.  <address
type> is a text string giving the type of the address that follows.
Initially “IP4” and “IP6” are defined.  <address> is the globally
unique address of the machine from which the session was created.
For an address type of IP4, this is either the fully-qualified domain
name of the machine, or the dotted-decimal representation of the IP
version 4 address of the machine.  For an address type of IP6, this
is either the fully-qualified domain name of the machine, or the
compressed textual representation of the IP version 6 address of the
machine.  For both IP4 and IP6, the fully-qualified domain name is
the form that SHOULD be given unless this is unavailable, in which
case the globally unique address may be substituted.  A local IP
address MUST NOT be used in any context where the SDP description
might leave the scope in which the address is meaningful.

In general, the “o=” field serves as a globally unique identifier for
this version of this session description, and the subfields excepting
the version taken together identify the session irrespective of any
modifications.

=========================
m=<media> <port> <transport> <fmt list>

=========================
m=audio 12778 RTP/AVP 0
=========================

m=video 49170/2 RTP/AVP 31

would specify that ports 49170 and 49171 form one RTP/RTCP pair and
49172 and 49173 form the second RTP/RTCP pair.  RTP/AVP is the
transport protocol and 31 is the format

31        H261            V                  90000                              [RFC4587]

session description may contain a number of media descriptions.
Each media description starts with an “m=” field, and is terminated
by either the next “m=” field or by the end of the session
description.

An example of a static payload type is u-law PCM coded single
channel audio sampled at 8KHz.  This is completely defined in the
RTP Audio/Video profile as payload type 0, so the media field for
such a stream sent to UDP port 49232 is:

m=video 49232 RTP/AVP 0

An example of a dynamic payload type is 16 bit linear encoded
stereo audio sampled at 16KHz.  If we wish to use dynamic RTP/AVP
payload type 98 for such a stream, additional information is
required to decode it:

m=video 49232 RTP/AVP 98

http://www.iana.org/assignments/rtp-parameters

=========================
m=audio 12778 RTP/AVP 0
=========================

Registry:
PT        encoding name   audio/video (A/V)  clock rate (Hz)  channels (audio)  Reference
——–  ————–  —————–  —————  —————-  ———
0         PCMU            A                  8000             1                 [RFC3551]

=========================
a=rtpmap:0 PCMU/8000
=========================

a=<attribute>
a=<attribute>:<value>

A media description may have any number of attributes (“a=” fields)
which are media specific.  These are referred to as “media-level”
attributes and add information about the media stream.

Attribute fields can also be added before the first media field; these
“session-level” attributes convey additional information that applies
to the conference as a whole rather than to individual media; an
example might be the conference’s floor control policy.

Attribute fields may be of two forms:

o property attributes.  A property attribute is simply of the form
“a=<flag>”.  These are binary attributes, and the presence of the
attribute conveys that the attribute is a property of the session.
An example might be “a=recvonly”.

o value attributes.  A value attribute is of the form
“a=<attribute>:<value>”.  An example might be that a whiteboard
could have the value attribute “a=orient:landscape”