TDM Pseudowires: “Circuit Breaker” Ideas David Black, EMC March 6, 20141TSVAREA, IETF 89 London

TDM Pseudowires Emulate fixed-bandwidth TDM (e.g., T1, E3) Transmission: ON or OFF (cannot adjust rate) TDM PWs known to run over IP – What happens if they compete with TCP, or other congestion-responsive traffic? Author team working (slowly) on a draft – draft-ietf-pwe3-congcons (expired, sorry) – What we’ve found applies to “circuit breakers” March 6, 20142TSVAREA, IETF 89 London

PW Background Pseudowire (PW) emulates a “wire” – Ethernet, Frame Relay, TDM telephone, FC, etc. – Mostly over MPLS, some over IP Significant PW congestion concerns arose – E.g., see RFC 3985 (Sec. 6.5) RFC 4553 (Sec. 8) Congestion usually not a problem in practice – Most PWs run over traffic-engineered MPLS – But some PWs run over IP, e.g., TDM PWs March 6, 20143TSVAREA, IETF 89 London

TDM Pseudowire Service Specified based on error rate (by ITU-T) – Error sampling period: 1 second – Two error levels (any error, BER > 1:1000 [severe]) BER = Bit Error Rate TDM service specification: Errored second percentages – Implication: If service specification not met, TDM PW may no longer be useful. Question: If a TDM PW competes with TCP, how does PW bandwidth compare to TCP throughput? – Depends on latency and error (drop) rate – Use PW service specification to bound error rate – PW latency based on TDM PW deployment considerations March 6, 20144TSVAREA, IETF 89 London

Good Examples: E3 PW, 1024 byte segments March 6, 20145TSVAREA, IETF 89 London

Not So Good Examples: E1 PW, 32 byte segments March 6, 20146TSVAREA, IETF 89 London

Congestion Reaction Considerations Reminder - RFC 3985 says: The comparison to TCP cannot be specified exactly but is intended as an "order-of-magnitude" comparison in timescale and throughput. – Upshot: the “Not So Good” examples may be ok. Need a runtime measure – Based on service specification and TCP throughput – With generous leeway/tolerance Be cautious about turning PW off – Not quick, has customer consequences March 6, 20147TSVAREA, IETF 89 London

Hypothetical Example Severely Errored Second Ratio (SESR): 0.2% – Service level not met when this is exceeded Look for multiple severely errored seconds (SESs) to avoid spikes Let’s try SES seconds / 0.2% = 1500 seconds -More often indicates a problem -Track last 3 SES occurrences -If older one is within 300 sec, do something? -NOTE: Both 3 and 300 are “phone numbers” -For example, not actually proposed for use! March 6, 20148TSVAREA, IETF 89 London

Generalizing Independent service level spec for traffic – Crucial input Use TCP throughput equation – Depends on RTT (2-way latency) and loss rate Monitor error rate and define threshold – Figure out what to do when threshold exceeded More importantly, *how/where* to do it: – TDM PW “circuit breaker” trip: Management plane, human network operator Probably not automatic – Approaches to other technologies will vary. March 6, 20149TSVAREA, IETF 89 London