Transport layer

Classical transport layer End-to-end Reliability retransmission Flow control vs Congestion control

Transport layer in sensor network Multi-hop “data-centric” transport service No endpoint address but group or cluster 1->N (downlink): controlled broadcast M->1 (uplink): data aggregation/processing Cooperative/collective paradigm Not competitive

Sensor network: traditional viewpoint Sources to sink communications Occasional loss is OK

New viewpoint Sink to sources communications Occasional loss is disastrous

Reliability in Sensor networks When reliability is required Sink to sources Reprogramming: binary Reconfiguration: script Lightweight

Pump slowly, fetch quickly (PSFQ) Customizable transport protocol Different application needs Ensure delivery with minimum requirements on routing infrastructure Minimum signaling traffic High error rate

How PSFQ? Source paces data slowly (PS) When sink detects message loss, quickly performs local recovery (FQ) Detection: sequence number Negative ACK Assumption: message loss is due to link error rather than congestion

PSFQ Negative ACK Hop by hop error recovery Packet loss rate: p Src and sink are n hops away Successful e2e delivery: (1-p)^n

E2e success rate

If multiple reXmission

Multi-modal operations Localize the loss event Store-and-forward approach

Multi-model operations Packet-forwarding mode Low error rate Store-and-forward mode High error rate

PSFQ: 3 functions Pump: message relaying Inject message File Id, file length, sequence number, TTL From user node to every sensor node Re-tasking (broadcasting) Fetch: relay-initiated error recovery Report: selective status reporting Reference application

pump User node broadcasts a packet every Tmin until all data segments are sent out Tmin is for local recovery Neighbors receive each segment and decrement TTL by 1 If TTL > 0 && no gap in sequence number, PSFQ sets a schedule (Tmin..Tmax) to forward the message If PSFQ heard the same message 4 times, schedule is canceled Tmax can be used to provide a loose statistical delay bound (e2e) Delay = Tmax * number of hops * number of fragments

fetch NACK message Loss aggregation Fetch timer Proactive fetch File id, file length, loss window Loss aggregation Window of lost packets Bursty loss is possible Fetch timer NACK at every timer expiration Only one-hop broadcasting Proactive fetch If next packet is not delivered after Tpro

Report From target node to user node Report message Header: the relaying node id Payload: a chain of node Ids and seq. numbers Source node will trigger by setting report bit in TTL field The last hop (final destination) will initiate this reporting What if no space to append more info? Create new message and send it first before relaying the old one

ESRT: Event-to-sink Reliable Transport

Problem definition For reliable temporal tracking, the sink must decide on the event every t units The sink derives a reliability metric r_i at every decision interval i Def1: the observed event reliability, r_i is the number of received data packets in decision interval i at the sink Def2: the desired event reliability, R is the number of data packets required for reliable event detection If r_i > R, the event is deemed to be reliably detected f: reporting rate

r vs f n: the number of source nodes CSMA-CA DSR

5 regions  = r/R, a normalized reliability

ESRT ESRT identifies the current state S_i For each interval i: _i, f_i A congestion detection mechanism ESRT derives a new _(i+1) and calculates the updated f_(i+1) for interval i+1 and determines the next state S_(i+1)

NC, LR Failure, power down of some nodes Packet loss due to link errors f_(i+1) = f_i / _i Multiplicative increase

NC, HR Reliability is overly achieved f_(i+1) = f_i * (1 + 1/_i)/2 Multiplicative Half the slope

C, HR Decrease reporting frequency Energy saving f_(i+1) = f_i / _i Multiplicative decrease

C, LR Worst state Aggressively decrease k: the number of decision intervals with state (C, LR) including this interval so, k >= 1

OOR Frequency is left unchanged f_(i+1) = f_i

Congestion detection Local buffer level monitoring Congestion indication condition Set the CN bit in the packet header

Open issue? End-to-end reliability is r arrival over R generation What if intermediate nodes know this context? Number of hops A intermediate node receives some packets (between r and R) Does it have to request retransmission?

CODA: congestion detection and avoidance

Congestion detection Buffer queue length Channel loading sampling Report rate/fidelity measurement

CODA design Open-loop hop-by-hop backpressure Receiver-based detection Minimum cost sampling Suppression message Closed-loop multi-source regulation Source sets regulate bit at the event packets ACK packets from the sink