Router Buffer Sizing and Reliability Challenges in MulticastTCP PerformanceSingle TCP Flow Router without buffersSummary Unbuffered LinkSlide 5Slide 6Single TCP Flow Router with large enough buffers for full link utilizationExampleIf flows are synchronizedIf flows are not synchronizedCentral Limit TheoremLoss Recovery in MulticastImplosionRetransmissionExposureIdeal Recovery ModelScalable Reliable MulticastSRM Request SuppressionDeterministic SuppressionSRM Star TopologySRM: Stochastic SuppressionSRM (Summary)Router Buffer Sizing and Reliability Challenges in MulticastAditya Akella02/28TCP Performance•Can TCP saturate a link?•Congestion control–Increase utilization until… link becomes congested–React by decreasing window by 50%–Window is proportional to rate * RTT•Doesn’t this mean that the network oscillates between 50 and 100% utilization?–Average utilization = 75%??–No…this is *not* right!Single TCP FlowRouter without buffersSummary Unbuffered LinktWMinimum window for full utilization•The router can’t fully utilize the link–If the window is too small, link is not full–If the link is full, next window increase causes drop–With no buffer it still achieves 75% utilizationTCP Performance•In the real world, router queues play important role–Window is proportional to rate * RTT•But, RTT changes as well the window–Window to fill links = propagation RTT * bottleneck bandwidth•If window is larger, packets sit in queue on bottleneck linkTCP Performance•If we have a large router queue  can get 100% utilization–But, router queues can cause large delays•How big does the queue need to be?–Windows vary from W  W/2•Must make sure that link is always full•W/2 > RTT * BW•W = RTT * BW + Qsize•Therefore, Qsize > RTT * BW–Ensures 100% utilization–Delay?•Varies between RTT and 2 * RTTSingle TCP FlowRouter with large enough buffers for full link utilizationExample•10Gb/s linecard–Requires 300Mbytes of buffering.–Read and write 40 byte packet every 32ns.•Memory technologies–DRAM: require 4 devices, but too slow. –SRAM: require 80 devices, 1kW, $2000.•Problem gets harder at 40Gb/s–Hence RLDRAM, FCRAM, etc.•Rule-of-thumb makes sense for one flow–Typical backbone link has > 20,000 flows–Does the rule-of-thumb still hold?If flows are synchronized•Aggregate window has same dynamics•Therefore buffer occupancy has same dynamics•Rule-of-thumb still holds.2maxWtmax2W�maxW�maxWIf flows are not synchronizedProbabilityDistributionB0Buffer SizeWCentral Limit Theorem•CLT tells us that the more variables (Congestion Windows of Flows) we have, the narrower the Gaussian (Fluctuation of sum of windows)–Width of Gaussian decreases with –Buffer size should also decreases withnCTnBBn21n1n1Loss Recovery in Multicast•Sender-reliable–Wait for ACKs from all receivers. Re-send on timeout or selective ACK–Per receiver state in sender not scalable–ACK implosion•Receiver-reliable–Receiver NACKs (resend request) lost packet–Does not provide 100% reliability–NACK implosionR1ImplosionSR3 R4R221R1SR3 R4R2Packet 1 is lost All 4 receivers request a resendResend requestRetransmission•Re-transmitter–Options: sender, other receivers•How to retransmit–Unicast, multicast, scoped multicast, retransmission group, …•Problem: ExposureR1ExposureSR3 R4R221R1SR3 R4R2Packet 1 does not reach R1;Receiver 1 requests a resendPacket 1 resent to all 4 receivers11Resend requestResent packetIdeal Recovery ModelSR3 R4R221SR3 R4R2Packet 1 reaches R1 but is lost before reaching other ReceiversOnly one receiver sends NACK to the nearest S or R with packetResend request1 1Resent packetRepair sent only to those that need packetR1 R1Scalable Reliable Multicast•Originally designed for wb (whiteboard)•Receiver-reliable–NACK-based•Every member may multicast NACK or retransmissionR1SRM Request SuppressionSR3R221R1SR3R2Packet 1 is lost; R1 requests resend to Source and ReceiversPacket 1 is resent; R2 and R3 no longer have to request a resend1XXDelay varies by distanceXResend requestResent packetDeterministic Suppressiondddd3dTimedatanackrepaird4dd2d3d= Sender= Repairer= RequestorDelay = C1dS,RSRM Star TopologySR221R3Packet 1 is lost; All Receivers request resendsPacket 1 is resent to all ReceiversXR4Delay is same lengthSR21R3 R4Resend requestResent packetSRM: Stochastic SuppressiondataddddTimeNACKrepair2dsession msg0123Delay = U[0,D2] dS,R= Sender= Repairer= RequestorSRM (Summary)•NACK/Retransmission suppression–Delay before sending–Delay based on RTT estimation–Deterministic + Stochastic components•Periodic session messages–Full reliability–Estimation of distance matrix among