Berikut adalah jawaban yg daku kumpulken berkaitan dengan tugas seputar Transport protokol.

1. Describe why an application developer may choose to run an application over UDP rather than TCP

UDP adalah sebuah connectionless transport protocol yang tidak memiliki connection setup, flow control, congestion control dan juga tidak reliable. Terlepas dari ketidakreliableannya, UDP mampu mengirim data dengan rate berapa saja walaupun tentu saja tidak djiamin data pasti akan sampai di penerima (ada kemungkinan terjadi data loss).

Karakterisik UDP yg demikian itu membuat Application developer lebih menyukai UDP ketika mereka membangun applikasi yang memiliki spesifikasi seperti berikut:

-         membutuhkan response yang cepat. UDP tidak memiliki connection state dan connection establishment sehingga mampu memberikan response yg cepat atas setiap request dari client.

-         mentolerir data loss. Beberapa applikasi tidak terlalu sensitive terhadap kehilangan data (selama kehilangan tersebut tidak significant), sehingga ketidak reliablean UDP tidak begitu masalah bagi applikasi seperti ini.

-         membutuhkan kontrol yang lebih baik atas apa yang akan dikirim dan kapan data akan dikirim. Mekanisme kontrol koneksi yg dimiliki TCP akan membuat applikasi menjadi tidak luwes untuk menentukan kapan saat yg tepat untuk mengirim data sehingga bisa menimbulkan delay yg tidak dapat ditoleransi. Di samping itu, TCP akan tetap berusaha mengirimkan data (walaupun akan membutuhkan waktu yg lama) ketika terjadi kongesti, padahal beberapa aplikasi membutuhkan rate pengiriman yang

-         Memerlukan pengiriman data pada lebih dari 1 client, baik applikasi broadcast ataupun multicast. TCP tidak mampu melakukan broardcast ataupun multicast.

Umumnya applikasi real-time bisa mentolerir data loss dan membutuhkan sending rate yang minimum sehingga pembangun applikasi berjenis ini menyukai UDP untuk membangun applikasinya. Apalagi jika applikasi itu membutuhkan multicast, UDP akan menjadi pilihan yg sangat disukai oleh developer aplikasi.

2. Is it possible for an application to enjoy reliable data transfer even when the application runs over UDP ? If so, how ?

UDP menjadi protokol yg tidak reliable karena protokol ini tidak dilengkapi dengan mekanisme acknowledge dan restransmission sehingga server tidak mengetahui apakah paket yang dikirimkan sampai dengan selamat atau tidak di penerima.

Walaupun demikian, UDP memiliki keunggulan karena protokol-nya lebih sederhana daripada protokol TCP yang memiliki mekanisme kontrol yang komplex. Kesederhanaan protokol UDP inilah yg membuat protokol ini mampu mengirim data lebih cepat.

Sebuah aplikasi bisa dibangun di atas UDP protokol sambil tetap mendapatkan transfer data yang reliable. Untuk mendapatkan hal itu, aplikasi tersebut harus membuat sendiri mekanisme acknowledge dan retransmission sehingga server bisa mengetahui apakah ada paket yang hilang dan perlu dikirimkan kembali sehingga kehilangan paket bisa diatasi.

3. Consider streaming stored audio. Does it make sense to run the application over UDP or TCP ? Which transport protocol does RealNetworks use ? Why ?

Streaming stored audio adalah kelas applikasi dimana server menyediakan audio terkompresi secara request-on-demand pada client. Audio tersebut sudah tersimpan di server, dan hanya akan dikirimkan pada client ketika si client meminta.

Applikasi dalam kelas ini tidak “live” dan tidak bersifat dua arah (Interactive), oleh karenanya tidak akan menjadi masalah jika user (client) diminta menunggu sebentar (satu hinga sepuluh detik bisa ditoleransi) sebelum audio terdengar.

Pada saat waktu tunggu tersebut, applikasi melakukan client buffering, yaitu mengambil beberapa bagian awal dari audio tersebut sehingga cukup untuk dimainkan. Kemudian applikasi akan memainkan bagian yang telah terdownload tersebut sambil mendownload bagian selanjutnya dari audio tersebut. Demikian yang terjadi terus menerus sehingga seluruh bagian terdownload dan dimainkan. Teknik ini dikenal dengan sebutan streaming.

Apakah masuk akal menjalankan “streaming stored audio” di atas protokol UDP atau TCP ? Sebenarnya masuk akal saja menggunakan TCP selama bandwith yg tersedia cukup memungkinkan sehingga waktu tunggu dan waktu memainkan audio lebih panjang daripada waktu yg diperlukan untuk mendownload bagian-bagian audio yang akan dimainkan selanjutnya.

Selain itu, Internet tidak memberikan jaminan bebas kongesti sehingga waktu delay yang ditimbulkan oleh kongesti ini juga harus diperhitungkan jika applikasi “streaming stored audio” dibangun di atas TCP.

Oleh karena itu, TCP hanya masuk akal digunakan oleh aplikasi “streaming stored audio” jika “Play time” lebih kecil daripada waktu download ditambah delay yg timbul karena kongesti.

Pada prakteknya, TCP retransmission dan TCP congestion control seringkali menimbulkan delay yg tidak bisa ditolerir karena mempengaruhi natural playout rate.

Sementara UDP lebih masuk akal untuk diterapkan pada aplikasi berjenis ini (karena UDP adalah protokol yg tidak komplex seperti TCP sehingga memungkinkan transfer rate yg tinggi pada kondisi apapun) asalkan diberi tambahan fungsi untuk memelihara qualify of service.

RealNetworks,  yang juga menjadi pelopor dalam produk streaming audio dan video, menggunakan UDP yang dibungkus dalam RTP (Real Time Protocol) dan RDT (RealNetwork’s Real Data Transport sebagai transport protokol-nya. RTP adalah Transport protokol untuk applikasi real-time yang menyediakan semantik untuk end-to-end delivery service pada data real-time, sementara RDT protokol proprietary milik RealNetworks yang sejenis dengan RTP. Pada aras applikasi, RealNetworks menggunakan RTSP (Real Time Streaming Protocol).

RTP dan RDT adalah Transport protokol yang berjalan di atas UDP. Protokol-protokol ini menggunakan UDP untuk mengirimkan data dari server ke client dengan dibantu oleh protokol lain untuk meminta pengiriman ulang paket jika ada paket yang hilang sehingga tidak diterima oleh client.

RTP menggunakan protokol RTCP (Real Time Control Protocol) untuk meminta pengiriman ulang, semetara RDT menggunakan UDP searah (simplex UDP) dari client ke server untuk meminta pengiriman ulang lost packet.

Mengapa RealNetworks menggunakan protokol RTP/RTCP dan RDT ? Karena RealNetworks menyediakan aplikasi streaming yg membutuhkan distribusi multicast, transfer rate yang tinggi, lancar (tidak tersendat-sendat walaupun jaringan sedang dalam kondisi sangat terbebani) dan juga membutuhkan pemeliharaan quality of service.

TCP tidak cocok untuk applikasi-applikasi RealNetworks karena TCP tidak memungkinkan distribusi multicast dan fungsi kontrolnya yg terlalu komplex memungkinkan terjadinya delay yg tidak bisa ditolerir, sementara UDP saja kurang cocok karena tidak menyediakan fungsi pemeliharaan quality of service.

4. Explain why a client/server can “unfairly” create many parallel simultaneous connections. What can be done to make the Internet truly fair ?

Pada dasarnya, jika tidak dibatasi oleh configurasi pada applikasi itu sendiri,  sebuah applikasi client/server bisa membuka beberapa koneksi TCP paralel secara simultan tanpa dihalangi oleh apapun. Sebagai contoh,  aplikasi browser seringkali menggunakan beberapa koneksi TCP secara paralel untuk mengambil beberapa object dari server pada sebuah web page. Kondisi ini akan menyebabkan applikasi ini bisa mendapatkan porsi bandwith yg lebih besar pada kondisi kongesti.

Mengapa hal ini bisa terjadi ? Karena transport layer tidak bisa mendeteksi applikasi mana yg sedang meminta koneksi lewat TCP. Jaringan hanya bisa mengenali mesin yg menjalankan applikasi tersebut (berdasarkan IP address) dan port number.

Sebagai contoh, seorang user menjalankan 3 applikasi telnet untuk menghubungi masing-masing 1 server akan dikenali sebagai 3 koneksi TCP oleh jaringan. Sementara seorang user lainnya, yg menjalankan hanya sebuah browser untuk membuka sebuah website dengan multiple object (katakanlah page tersebut memiliki 3 object), akan dikenali juga sebagai 3 koneksi TCP oleh jaringan.

Kondisi ini adalah kondisi yg tidak fair karena masing-masing applikasi telnet hanya mendapatkan 1/6 dari seluruh bandwith sementara applikasi browser mendapatkan ˝ porsi dari bandwith yg tersedia (walaupun hanya satu applikasi yg dijalankan) karena browser-nya menggunakan multiple parallel TCP connection.

Apakah yg bisa dilakukan untuk membuat  Internet benar-benar fair ?

Ada beberapa cara yang alternatif yang mungkin bisa dilakukan untuk membuat Internet menjadi lebih fair, yaitu:

1.      Integrated Congestion/Lost Recovery. Alternatif ini menawarkan kontrol kongesti yang lebih baik sehingga multiple parallel TCP connection tidak membuat applikasi menjadi aggresif dan menyebabkan kondisi unfairness tanpa melakukan perubahan di sisi applikasi sehingga applikasi yang sudah ada tetap bisa digunakan tanpa harus ditulis ulang. Untuk mendapatkan kondisi ini, modifikasi dilakukan pada TCP dengan mengintegrasikan congestion control dan data loss recovery pada koneksi-koneksi parallel tersebut. Modifikasi ini dikenal dengan sebutan TCP-Int.

2.      Application-Level Multiplexing. Pada solusi ini, perubahan tidak dilakukan pada protokol TCP, melainkan pada application protocol. Applikasi tidak lagi menggunakan multiple parallel connections untuk mendownload beberapa object pada sebuah page, melainkan hanya menggunakan satu koneksi TCP saja dan mengirimkan beberapa stream data setelah digabungkan terlebih dulu.

Contoh implementasinya adalah antara lain: Persistent-connection HTTP, SCP (Session Control Protocol) dan MUX protocol.

Terlepas dari berbagai peningkatan kinerja yang didapatkan pada solusi no-2, alternatif ini juga mempunyai kekurangan yaitu:

• Membutuhkan penulisan ulang applikasi, yang juga harus dilakukan pada sisi client dan server
• Tidak memungkinkan penggabungan stream yang dikirimkan oleh applikasi-applikasi yang berbeda
• Multiplexing bisa menyebabkan terhentinya pengiriman data yang seharusnya independent karena salah satu stream gagal terkirim.

TCP-Int tidak membutuhkan penulisan ulang applikasi dan memungkinkan applikasi-applikasi yang dirancang untuk melakukan multiple parallel connections bisa mendapatkan jatah bandwith yg fair.

5. Read the research literature to learn about “TCP friendly”. Write a one-page summary on TCP friendly

Seperti telah dituliskan pada jawaban no-1, UDP tidak memiliki kontrol kongesti sehingga memungkinkan applikasi yang berjalan di atas protokol ini mengirimkan data ke jaringan dengan rate semaunya tanpa memperdulikan apakah jaringan sedang kongesti atau tidak.

“Ketidak pedulian UDP pada kongesti” ini akan menyebabkan pembagian bandwith yg tidak fair pada applikasi-applikasi berbasis TCP yg akan mengurangi rate transfer-nya ketika jaringan dalam keadaan kongesti.

 “TCP friendly research” adalah riset-riset tentang algoritma kontrol kongesti untuk aplikasi-aplikasi yang tidak berbasis TCP.

Selain alasan di atas, penambahan fungsi kontrol kongesti pada applikasi non-TCP ini juga dibutuhkan karena:

• Aplikasi yang melakukan kontrol kongesti akan menyebabkan penggunaan network lebih efisien dan oleh karenanya secara umum akan meningkatkan kinerja jaringan.
• Aplikasi yang bisa beradaptasi di jaringan pada rentang bandwith yg lebih luas sehingga membuat applikasi tersebut lebih berguna di dunia Internet.
• Algoritma kontrol kongesti mencegah jaringan memasuki kondisi Congestive Collapse, yaitu suatu kondisi dimana network link terbebani sangat berat  sehingga tidak bisa digunakan dengan baik.
• Pada suatu saat nanti, kontrol kongesti ini mungkin akan wajib dimiliki oleh aplikasi-aplikasi sebagai syarat untuk menggunakan jaringan. Jika ada yang tidak memiliki kontrol kongesti, maka applikasi tersebut akan dihukum oleh jaringan (misalnya mungkin dengan memilih untuk menghentikan paket-paket yg dikirimkan oleh applikasi tersebut sepanjang terjadinya kongesti)

Beberapa algoritma yang telah dan tengah dikembangkan untuk membuat protokol non-TCP menjadi lebih bersahabat (“friendly”) adalah antara lain:

• J. Mahdavi, S. Floyd, TCP-Friendly Unicast Rate-Based Flow Control
• D. Sisalem, H. Schluzrinne, The Loss-Delay Adjustment Algoritm: A TCP-Friendly Adaptation Scheme
• D. Sisalem, F. Emanuel, H. Schulzrinne, The Direcy Adjustment Algorithm: A TCP-Friendly Adapation Scheme
• Jitendra Padhye, Jim Kurose, Don Towsley and Rajeev Koodly, A TCP-Friendly Rate Adjustment Protocol for Continuous Media Flows over Best Effort Networks
• Sally Floyd, Mark Handley, Jitendra Padhye, and Joerg Widmer, Equation-based Congestion Control for Unicast Applications: the Extended Version

Unicast Rate-Based Flow Control, yang dipubliksasikan oleh J Mahdavi & Sally Floyd ini, adalah sebuah teknik pengaturan flow untuk applikasi unicast yg tidak menggunakan TCP pada transport layer. Rate-Based Applications, yaitu applikasi-applikasi yang tidak menggunakan congestion window untuk mengontrol rate pengiriman data dan memilih sendiri rate yang pantas untuk applikasi tersebut, harus memilih untuk mengirimkan paket-paket-nya dengan rate yang tidak lebih tinggi daripada koneksi TCP untuk menjadi applikasi yang TCP-Friendly. Selama proses pengiriman data, Applikasi harus memantau keseluruhan paket loss untuk mengetahui apakah rate yg digunakan masih memungkinkan bagi TCP untuk mendapatkan setidaknya jatah bandwith yg sama.

Jika masih memungkinkan, Applikasi akan terus mengirimkan data dengan rate yg sama. Jika tidak, applikasi akan mengurangi rate menjadi setengah dari rate sebelumnya sambil terus memantau packet loss. Jika paket loss berkurang, maka applikasi akan memperbesar kembali rate-nya. Applikasi juga perlu dilengkapi dengan kemampuan menghitung bandwith yg bisa didapatkan TCP dengan mengetahui MTU (dengan menggunakan MTU Discovery Algorithm), RTT dan current loss rate.

The Loss-Delay Based Adjustment Algorithm (LDA) dan The Direct Adjusment Agorithm (DAA) juga menggunakan packet loss untuk mengetahui apakah applikasi harus mengurangi, mempertahankan, atau memperbesar rate-nya. Perbedaannya adalah bahwa LDA dan DAA menggunakan RTP untuk mendapatkan informasi feedback.

Rate Adjustment Protocol yg ditawarkan oleh Jitendra Padhye, Jim Kurose, Don Towsley and Rajeev Koodly juga menggunakan informasi packet loss untuk mengetahui kondisi jaringan. Sedikit berbeda dengan Rate-Based Flow Control, Algoritma ini tidak menghitung dan mengubah rate-nya pada setiap pengiriman paket. Penghitungan hanya secara akumulatif pada setiap M kali (round time) dan kemudian dilihat apakah ada paket loss pada round tersebut. Jika tidak ada loss paket, pengirim akan menduplikasi rate-nya. Dan jika tidak, pengirim akan mengurangi rate-nya sesuai dengan hasil perhitungan menggunakan TCP-friendly equation.

Pada umumnya, riset-riset mengenai TCP-Friendly menggunakan informasi packet loss untuk menentukan apakah pengirim harus mengurangi, mempertahankan, atau memperbesar rate pengiriman-nya. Yang membedakan algoritma yang satu dengan yang lain adalah bagaimana masing-masing algoritma itu mendapatkan informasi packet loss, menggunakan informasi packet loss untuk menentukan rate, dan kapan perubahan rate dilakukan. Berbagai kembangan lainnya, seperti Equation-based Congestion Control for Unicast Application yang dipublikasikan oleh Sally Fold , Mark Handley dan Joerg Widmer juga meneliti mekanisme untuk penyediaan pencegahan terjadinya osilasi yang tidak perlu, pencegahan munculnya derau yang tidak perlu, serta robustness pada rentang skala waktu yang lebar.