Transport Layer Rekayasa Internet Week 3 Dosen: S. Indriani L, M.T Genap 2012/2013

Transport services and protocols Menyediakan logical communication antar proses aplikasi yang berjalan pada host yang berbeda Protokol transport berjalan di end systems Layanan layer transport vs layer network : network layer: transfer data antar end systems transport layer: transfer data antar proses Mengandalkan layanan layer network application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

Transport-layer protocols Layanan layer transport pada Internet : reliable, in-order unicast delivery (TCP) congestion flow control connection setup unreliable (“best-effort”), unordered unicast atau multicast delivery: UDP Layanan yg tidak tersedia: real-time bandwidth guarantees reliable multicast application transport network data link physical network data link physical network data link physical network data link physical logical end-end transport network data link physical network data link physical application transport network data link physical

Multiplexing/demultiplexing Demultiplexing: mengirimkan segmen yang diterima ke proses layer aplikasi yang sesuai receiver P3 P4 application-layer data M M application transport network segment header P1 P2 M M application transport network application transport network segment H t M H n segment

Multiplexing/demultiplexing Mengumpulkan data dari beberapa proses aplikasi, membungkus data dgn header (header digunakan Pada proses demultiplexing) 32 bits source port # dest port # other header fields multiplexing/demultiplexing: Berdasarkan IP address dan nomor port pengirim dan penerima application data (message) TCP/UDP segment format

Multiplexing/demultiplexing: contoh source port: x dest. port: 23 Web client host C host A server B source port:23 dest. port: x Source IP: C Dest IP: B source port: y dest. port: 80 Source IP: C Dest IP: B source port: x dest. port: 80 port use: simple telnet app Source IP: A Dest IP: B source port: x dest. port: 80 Web server B Web client host A port use: Web server

UDP: User Datagram Protocol [RFC 768] “best effort” service, segmen UDP dapat megalami: lost Dikirimkan tidak terurut connectionless: Tidak ada handshaking antara pengirim dan penerima UDP Setiap segmen UDP ditangani sendiri-sendiri tanpa tergantung pada segmen yang lain Mengapa UDP? Tidak perlu pembentukan koneksi (mengurangi delay) simple: tidak ada informasi state baik di pengirim maupun penerima Header : pendek Tidak ada kendali kongesti

UDP Penggunaan UDP yang lain untuk: Biasa digunakan untuk aplikasi streaming multimedia loss tolerant rate sensitive Penggunaan UDP yang lain untuk: DNS SNMP Bila ingin melakukan reliable transfer menggunakan UDP: tambahkan reliability di layer aplikasi application-specific error recover! 32 bits source port # dest port # Length, in bytes of UDP segment, including header length checksum Application data (message) UDP segment format

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581 point-to-point: Satu pengirim utk satu penerima reliable, in-order byte stream: pipelined: Kendali kongesti dan flow control TCP menetapkan ukuran window Ada buffer di pengirim dan penerima full duplex data: Aliran data dua arah pada koneksi yang sama MSS: maximum segment size connection-oriented: Ada handshaking sebelum pertukaran data flow controlled: sender will not overwhelm receiver

Struktur segmen TCP source port # dest port # application data 32 bits application data (variable length) sequence number acknowledgement number rcvr window size ptr urgent data checksum F S R P A U head len not used Options (variable length) URG: urgent data (generally not used) counting by bytes of data (not segments!) ACK: ACK # valid PSH: push data now (generally not used) # bytes rcvr willing to accept RST, SYN, FIN: connection estab (setup, teardown commands) Internet checksum (as in UDP)

TCP : Nomor urut segmen dan ACKs Nomor byte pertama pada suatu aliran segmen data ACKs: Nomor urut byte berikutnya yang diharapkan dari sisi yg lain cumulative ACK Q: bagaimana receiver menangani segmen yg tak terurut Tidak ada dlm spesifikasi TCP (tergantung pengembang program) Host A Host B User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario

TCP ACK generation [RFC 1122, RFC 2581] Event in-order segment arrival, no gaps, everything else already ACKed one delayed ACK pending out-of-order segment arrival higher-than-expect seq. # gap detected arrival of segment that partially or completely fills gap TCP Receiver action delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK immediately send single cumulative ACK send duplicate ACK, indicating seq. # of next expected byte immediate ACK if segment starts at lower end of gap

TCP: retransmission scenarios Host A Seq=92, 8 bytes data ACK=100 loss timeout time lost ACK scenario Host B X Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 Seq=100 timeout ACK=120 Seq=92, 8 bytes data ACK=120 time premature timeout, cumulative ACKs

TCP Flow Control flow control receiver: secara eksplisit memberi tahu pengirim ruang buffer yang masih kosong RcvWindow field dalam segmen TCP sender: menjaga agar jumlah data yang dikirimkan (yg belum di-ACK) lebih kecil drpd RcvWindow terakhir yg diterima Mencegah pengirim membanjiri penerima dengan data (shg buffer tidak overflow) RcvBuffer = Ukuran buffer TCP Receive RcvWindow = sisa Buffer space receiver buffering

TCP Round Trip Time dan Timeout Q: cara menetapkan harga TCP timeout? Lebih lama dari RTT RTT bervariasi Bila terlalu pendek: premature timeout Bisa ada retransmisi yg tdk diperlukan Bila terlalu lama: reaksi thdp segmen yg hilang akan lambat Q: Cara mengestimasi RTT? SampleRTT: waktu sejak segmen dikirimkan sampai ACK diterima ignore retransmissions, cumulatively ACKed segments SampleRTT akan bervariasi, sehingga bila ingin diperoleh hasil yang lebih tepat : Lakukan beberapa kali pengukuran

Menetapkan timeout EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT Harga tipikal x = 0,1 Menetapkan timeout EstimtedRTT ditambah “safety margin” large variation in EstimatedRTT -> larger safety margin Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT|

TCP Congestion Control Pengendalian end-to-end (tdk ada bantuan dari jaringan) Laju transmisi dibatasi oleh congestion window size, Congwin, dari suatu segmen Congwin Segmen w, masing-masing dengan byte MSS yg dikirimkan dalam satu RTT: throughput = w * MSS RTT Bytes/sec

TCP congestion control: “probing” untuk bandwidth yg dpt digunakan: ideally: mengirim secepat mungkin (Congwin sebesar mungkin) tanpa loss Naikkan Congwin sampai terjadi loss (congestion) Bila terjadi loss: turunkan Congwin, lalu mulai lagi melakukan probing (increasing) Ada dua fasa slow start congestion avoidance Variable yang penting: Congwin threshold: mendefinisikan threshold antara fasa slow start dengan fasa kendali kongesti

TCP Slowstart Host A Host B Slowstart algorithm one segment initialize: Congwin = 1 for (each segment ACKed) Congwin++ until (loss event OR CongWin > threshold) RTT two segments four segments Kenaikan exponential (per RTT) dalam ukuran window (tidak begitu lambat !) loss event: timeout (Tahoe TCP) dan/atau bila ada ACK duplikasi (Reno TCP) time

TCP Congestion Avoidance /* slowstart is over */ /* Congwin > threshold */ Until (loss event) { every w segments ACKed: Congwin++ } threshold = Congwin/2 Congwin = 1 perform slowstart 1 1: TCP Reno skips slowstart (fast recovery) after three duplicate ACKs