<%BANNER%>

Multitrouting behavior in stream control transmission protocol

University of Florida Institutional Repository
xml version 1.0 encoding UTF-8
REPORT xmlns http:www.fcla.edudlsmddaitss xmlns:xsi http:www.w3.org2001XMLSchema-instance xsi:schemaLocation http:www.fcla.edudlsmddaitssdaitssReport.xsd
INGEST IEID E20110109_AAAAYQ INGEST_TIME 2011-01-09T23:18:52Z PACKAGE UFE0001189_00001
AGREEMENT_INFO ACCOUNT UF PROJECT UFDC
FILES
FILE SIZE 8289 DFID F20110109_AACSOL ORIGIN DEPOSITOR PATH gopalakrishnan_j_Page_085thm.jpg GLOBAL false PRESERVATION BIT MESSAGE_DIGEST ALGORITHM MD5
31188bd7dd175cd31f2e00bac7ec0b8f
SHA-1
3307a2cc265d0482ca180ae22b7a585b67926754
1232 F20110109_AACSNW gopalakrishnan_j_Page_050thm.jpg
454f37b65b9f1234d96aa59f6f0730da
5161b45e9b7cb3159987442a0312480b0f75974d
7150 F20110109_AACRLJ gopalakrishnan_j_Page_055thm.jpg
36bd5f18804043e5341a5255757662cf
7f314d66907e5129347482e43664d93bfee4d5e9
89954 F20110109_AACRKU gopalakrishnan_j_Page_051.jpg
31db1ff669f4847d50f61e80df719de8
925567ce63c06df869e3e2ff6eb3fbafed5a9188
7137 F20110109_AACSPA gopalakrishnan_j_Page_103thm.jpg
63b6110dff5443d36cee3d75461a871e
bc75558a8a2bd3d89bbbd7f3797a5de9b8caab31
31822 F20110109_AACSOM gopalakrishnan_j_Page_086.QC.jpg
45259d8c6771838108e53bc57ee66626
935039df635338ba1396b6eae7d9c2d2895373bf
7241 F20110109_AACSNX gopalakrishnan_j_Page_051thm.jpg
8f6621c6fa781a1de59998bc5e553530
ca52691a50333e78a1b9ec80d49d103a8cd66b18
8541 F20110109_AACRLK gopalakrishnan_j_Page_089thm.jpg
5f1b12d634fdf4f320d354d90423a422
53dcc45053f39e70e6c99e9bfa01b418bafed7cb
85069 F20110109_AACRKV gopalakrishnan_j_Page_095.jpg
43a656c2a42e7f224578e25d1950990a
1a3e880cacc96658b83f8382911621a5343a97d4
28660 F20110109_AACSPB gopalakrishnan_j_Page_104.QC.jpg
46e40a02fdb9c3798d418f167b081406
46d2318dee5e2e12f77e84cbf874e60168c102e9
27616 F20110109_AACSNY gopalakrishnan_j_Page_052.QC.jpg
e04dd0242824e9e1f01cdab491d0f659
057f81d12f43b2e456c407d7f0fe6a6730038385
1329 F20110109_AACRKW gopalakrishnan_j_Page_107.txt
1527144128de16c98e4a53980656c019
5381b1e68704c0151b32e9ff88243fa07efed365
4700 F20110109_AACSPC gopalakrishnan_j_Page_105thm.jpg
8532a8dfd1de548551514332531b608b
5f2517513d42ca29e2b7146b2c5c3eb5f3993127
30461 F20110109_AACSON gopalakrishnan_j_Page_087.QC.jpg
4a1d03d72d6b52e90d2f849fed0dba29
471820f129dcce261e2a424a1e8c29b217c65274
25678 F20110109_AACSNZ gopalakrishnan_j_Page_053.QC.jpg
f19b4fcafe0c178dea7fd2e8c6d3c198
0dea733f40993c936ab67ac367216e569d4379eb
1682 F20110109_AACRMA gopalakrishnan_j_Page_096.txt
d885e36bbf5d9dfc8a6f458619a8013e
b53370074183a4c8df9a821f37258a92f4c94b11
9441 F20110109_AACRLL gopalakrishnan_j_Page_036.QC.jpg
4179aca3c31bb4807a4703f2257f2ce7
f40a783d6be1ab01bcaaaebb98ecaa6420bc7daa
2053 F20110109_AACRKX gopalakrishnan_j_Page_091.txt
045ff1c8b83cb5d6634eb7102b4a33bb
6107aa828cecfd76fd1893d395b1024fa64fcf18
16600 F20110109_AACSPD gopalakrishnan_j_Page_107.QC.jpg
8ee5fe519e9b4cc60b345d1a8ae547b9
d64f013a3884ca481f236b14817e4e8089bb1253
36086 F20110109_AACSOO gopalakrishnan_j_Page_089.QC.jpg
ab74b9563f42a2e17f8635ad5db1944d
9bfe847fb9f46329ac7e2d80b41f4800bb2cea95
60839 F20110109_AACRMB gopalakrishnan_j_Page_107.jp2
1720a61e2675678eecf25b3ed712aabd
411a563ba2dfcdc083734fc1922404395355fa00
100586 F20110109_AACRLM gopalakrishnan_j_Page_102.jp2
a06e2d4773273e5584916b24de9fd005
9e00aa802adfd46b05516733f9fe6c306e70e1f7
1809 F20110109_AACRKY gopalakrishnan_j_Page_095.txt
ab9c5a58a0f7633f63ce64a8e50ca1da
029d4bf8f98c6248ae75c92dbe4d8f14d321874c
4396 F20110109_AACSPE gopalakrishnan_j_Page_107thm.jpg
ad408419a69e6365b484d87b837da472
6b0cc96ebd91501764b02e44867a2a2ab2cf0b66
35393 F20110109_AACSOP gopalakrishnan_j_Page_091.QC.jpg
2581dc26af8c1e22957f6d572e9db70a
8ca3f91f051afaaf29b1347ae03263c98c94d6c1
4880 F20110109_AACRMC gopalakrishnan_j_Page_012thm.jpg
7fdd498cffc5a36fb6b33ee38fd4ae3f
285a969f59639bc773d9342873fef337331e35de
38197 F20110109_AACRLN gopalakrishnan_j_Page_093.pro
93d6a71219cd6fdd5cac4d042af59bdc
848815fd8b41c33c9b36f55d823d981d580e9c51
43821 F20110109_AACRKZ gopalakrishnan_j_Page_084.pro
03ee4052fd6adaf41fc7acf2bf9cef47
ddb7dd1cf30d8115b70ee03465efde3747e7a7b4
5681 F20110109_AACSPF gopalakrishnan_j_Page_109thm.jpg
c5c35096220be7319b9dbf088d313537
fb52f56d412a4b5757a40a009bce3a559974bf3e
7410 F20110109_AACSOQ gopalakrishnan_j_Page_092thm.jpg
cf8624fee67b6b74f604768ec3e9b166
9d77eb655591cdaaf3bd0ba149b975dea8352988
1782 F20110109_AACRMD gopalakrishnan_j_Page_035.txt
a9c313cefb613a7a83068023d3de0616
8a3503ddd185b91345c389d604b2e9976baf7828
28349 F20110109_AACRLO gopalakrishnan_j_Page_058.QC.jpg
67dfa1954eaabcf4975522d2cccb0b1d
cec1d3a24fcdb8d5371c836f0d56057becd6a0b8
5245 F20110109_AACSPG gopalakrishnan_j_Page_110thm.jpg
4a5c70c5282cc537f2fb69cd5a262ed4
23789b0adc686946a23ea993f6aef8616d085ac1
7859 F20110109_AACSOR gopalakrishnan_j_Page_093thm.jpg
c8b0d63cbafabdeaa6fb3f2638c139c1
c1288903f903a000fd4b1a8269e0951c397e4d7e
38664 F20110109_AACRME gopalakrishnan_j_Page_106.pro
52ae12bb742c1e5197e8de4fa11dd7e0
79e22dcede148fe51f3341238c1992ebe93db638
88025 F20110109_AACRLP gopalakrishnan_j_Page_058.jpg
8d381f40699e58cad923ec262e511921
bb814764f7105758d070f2ce8a544df8333d42ac
18448 F20110109_AACSPH gopalakrishnan_j_Page_111.QC.jpg
07403d2e4cd304a15b72582e1f909219
7ecffd8c4ff7653167d22f8fcb734913cb679ee7
25921 F20110109_AACSOS gopalakrishnan_j_Page_094.QC.jpg
fbb8fb64db8604180c2c0ec45d6ca148
33a223261490c99a0df1ce44a47d81f89739dd06
40970 F20110109_AACRMF gopalakrishnan_j_Page_052.pro
2966e2fe520b2fc8319e039bd941dcfe
1545406211efb46f37c21f9f5d58eeae5da6af66
4686 F20110109_AACRLQ gopalakrishnan_j_Page_050.pro
fde70b7de1977f438d51b3188bd0d20b
7640db44d1517691a04b597c613c7c9344150f5f
4772 F20110109_AACSPI gopalakrishnan_j_Page_111thm.jpg
dc350228795868a5a1bbe31fc209eeb4
39727a5c3bc3501e668ee2908a1ea192b239a59f
31518 F20110109_AACSOT gopalakrishnan_j_Page_097.QC.jpg
386cc4af06bbbeeef834c54cdb3a9587
0591a09c670047e52dae3043c36c3ca37ffc9ffc
59296 F20110109_AACRMG gopalakrishnan_j_Page_004.jp2
783e61871cc9f23ff71f8563af33a632
25ed43ce5f9dc3e64d0a2d3a19e1f64b92b6968b
1053954 F20110109_AACRLR gopalakrishnan_j_Page_083.tif
6ae0750fa08ab5c297c0a1fced3aadbb
e3286a7753c7ca2b878edc8a93e40a13de786daa
6000 F20110109_AACSPJ gopalakrishnan_j_Page_113thm.jpg
07036a8acdaf3ac87e5cc683154ffd64
4f57d27acb3eca498e2139350da3079afc0fab71
4711 F20110109_AACSOU gopalakrishnan_j_Page_098.QC.jpg
04a3bd7158742a14c27bd384c70c9fcb
9cc5f790b571245ef912256d4cd6d650fd13229e
4800 F20110109_AACRMH gopalakrishnan_j_Page_050.QC.jpg
3c2058ccf092d05af9e574ccca806bbb
51be5532bbd0b2d31cb9ea80d52c095eb0ad08d3
49088 F20110109_AACRLS gopalakrishnan_j_Page_072.pro
93adfd76c7db68cfaa0d4ec2da9faf41
393dca291cfa96eee686e95dc94a85b585bbdd84
22102 F20110109_AACSPK gopalakrishnan_j_Page_114.QC.jpg
ef7083dccf9392f9883a532c4f166902
b334e7bdd3781fc4744a3a87501deebcd82a18b7
27252 F20110109_AACSOV gopalakrishnan_j_Page_099.QC.jpg
6c64af219b11cfb1c51ab94879b3b6bc
57caccb1271aad9f446c389486435e3524996f98
25271604 F20110109_AACRMI gopalakrishnan_j_Page_009.tif
1014d63dba7595de8cf94750ada8d6e1
737f525d633597eadde5f74184a739a49b8d5d8a
45909 F20110109_AACRLT gopalakrishnan_j_Page_045.pro
4aa6dda4d1aa3ba3e6e0d087c3f97892
4174d8c00a044f7722cdb910dc1ceaf7b03f7126
5246 F20110109_AACSPL gopalakrishnan_j_Page_114thm.jpg
2a63178c9839c88b8be38743dfceb45f
0a5215947f0c8a079587c4b1f5b18e5df7e9e876
6903 F20110109_AACSOW gopalakrishnan_j_Page_099thm.jpg
e2ce2668898f51572bc84ac08aa26add
bb1c7ab5925efe3259162d97757c8cea3a09fbd8
23041 F20110109_AACRMJ gopalakrishnan_j_Page_011.QC.jpg
0f2f8ffe73cd5bec840cdbaa5f9a92f9
0ec888abba9e04ba7c67fba72471816b7a90adf0
2605 F20110109_AACRLU gopalakrishnan_j_Page_065.txt
905e6928ac901b3c6212c19eb98dafd0
ab80077f54ff3fb7fb38eb6e6c993986b3942fd0
30264 F20110109_AACSPM gopalakrishnan_j_Page_116.QC.jpg
014041ba7d3b51527a16740057a17f2d
10d31a0a5054ea7b9269c562dff6c59af490bff5
32250 F20110109_AACSOX gopalakrishnan_j_Page_100.QC.jpg
f9b9f289d762765633527aee3fce3f7c
c2f83441fe87061974a4b0f54ad6e953204aad21
2287 F20110109_AACRMK gopalakrishnan_j_Page_061.txt
b36274cea28c0f7ab10935d4c866029f
e5d5db3b9f5b0cc760c72d87de99516a5ee40efa
2380 F20110109_AACRLV gopalakrishnan_j_Page_071.txt
06f4d8ed6c1e3b0996504fa506b9a96b
d6980acad7a5da937dc1e946373dc91731e4a406
35424 F20110109_AACSPN gopalakrishnan_j_Page_117.QC.jpg
e5acc8b94c2e410e00be5bb366d510c2
7a441b743097e0140360841046a76c6971df01b6
7918 F20110109_AACSOY gopalakrishnan_j_Page_100thm.jpg
8aca275c87373b2164f499ddec524487
596b234e0772bf96ee9751c0349a5eed5707c5d2
45021 F20110109_AACRML gopalakrishnan_j_Page_046.pro
858021fcd67cbd619e2de4f009c8df65
8ceee8588d6259587d2dd2d2f2a52a752ee1bf4b
F20110109_AACRLW gopalakrishnan_j_Page_005.tif
f569fcdd7fbe657636bb91e4759f33ed
da90de199985f55e4e0f5ab1a01ea9cf181bd48d
30059 F20110109_AACSOZ gopalakrishnan_j_Page_101.QC.jpg
f60d0eee9c9ad904a6b594c2ab84ec17
3aa842cd5ead903563857f2cab16d7615de2c73d
6123 F20110109_AACRLX gopalakrishnan_j_Page_035thm.jpg
ba3ab698b6307f37635d1fdfbed38368
51290e1abf068002c3f8eeaa343f8ad5e4dd68a0
7591 F20110109_AACRNA gopalakrishnan_j_Page_067thm.jpg
76951f3c81728ea4dd1c33414c27835f
0e1fe80f0c95570768f7fc19f4a9bd4734145ade
6320 F20110109_AACSPO gopalakrishnan_j_Page_118thm.jpg
de8aa6dbbc9276ddca8a44506dbac01b
5785a81684944f3c2e0b11a7182ef531c1463d9c
13535 F20110109_AACRMM gopalakrishnan_j_Page_098.jp2
6c560722e4de99768db383f9b84580de
4e3a2a0956adf28320fc3e63df6167ec51b5f7b2
5929 F20110109_AACRLY gopalakrishnan_j_Page_112thm.jpg
3065a6c108e8e842979e124d8ca40a0d
99947d079353a6f560e459b95eea07ecd6c76d37
21215 F20110109_AACRNB gopalakrishnan_j_Page_110.QC.jpg
442668bad046470b37201b28e4e67f04
a359165bfc9ac9423f3add6dbe81d1d21143f0fa
4130 F20110109_AACSPP gopalakrishnan_j_Page_119thm.jpg
6da1b5b7bbe0a838cb5b1e649ef057bd
626ea25185cfd471121ab8965119f5a6dd072205
F20110109_AACRMN gopalakrishnan_j_Page_081.tif
b330f227a062e094cc0d1116a05a2ce6
40056aa757857309dd88c3bbbd667f93b0386aa6
30133 F20110109_AACRLZ gopalakrishnan_j_Page_015.QC.jpg
5d7b15ad51602cd32efe5ff67a9a63e1
ae1b5f9565650d918629a5fc1f8faf6e9e03247b
99556 F20110109_AACRNC gopalakrishnan_j_Page_085.jpg
d3c7d1df7897d15c87acc6c9538ddc26
fd72201e649558631395a69c2cee028ccb35c1b5
142689 F20110109_AACSPQ UFE0001189_00001.mets FULL
87ca78c14db6b6d7545eb2d7de6a493d
b47034b9c283cf60bf660bad3a9388194d47bf49
107507 F20110109_AACRMO gopalakrishnan_j_Page_019.jp2
c53412cdcf13b6ec2e2315b69eaaf5a3
82ca982e694cae0ebe38854c82e57ea3beb4528a
23537 F20110109_AACRND gopalakrishnan_j_Page_025.QC.jpg
70d172464b4fa7bdbbb95e4f9955aff4
7192e58fb7feaf9155f5879756c15a9e26dd7f58
F20110109_AACRMP gopalakrishnan_j_Page_098.tif
595c39840578398ff1d3ea7cb6bea15d
d5e7b5a675201fc25bf1eaa40bef5922289cbfee
1896 F20110109_AACRNE gopalakrishnan_j_Page_023.txt
e4e8d0a8fbc1081e8c98d7964ca9ac5a
cddcea0d60334494c49fe97b685b84dc92adcbb4
70005 F20110109_AACRMQ gopalakrishnan_j_Page_027.pro
dc7bdf1c0cf3cece82883eeb3dc7bd3a
90b78ff347c93f060f798edda6783d18494ed978
32778 F20110109_AACRNF gopalakrishnan_j_Page_069.QC.jpg
72eda16a22df15e83a3d4688dacf4e20
78463f07b9b58ae5b38889246fec3514acf68fcf
35270 F20110109_AACRMR gopalakrishnan_j_Page_080.QC.jpg
8201c4832b1d2f0e3aa7649254770d68
f0ce4eb92552e8998d7a0e38e1c0124203003113
6244 F20110109_AACRNG gopalakrishnan_j_Page_025thm.jpg
89294ba7bd4dd4cc3b58fb37a45c0143
74cd80d751a62719fd3ce61fd62c077d95ff4460
75175 F20110109_AACRMS gopalakrishnan_j_Page_025.jpg
7c3e1da1ca56d1a59250be1a942ac62e
2eadd7481dc6ca969c920d645e14733980c5545b
1051973 F20110109_AACRNH gopalakrishnan_j_Page_006.jp2
2412d6906cb5f51e4743012521b195c0
8a1275d5b2950b767e8d9d0253fe3faf333bf365
8325 F20110109_AACRMT gopalakrishnan_j_Page_064thm.jpg
d2b5969f65f9fe3ad66693f8b01233f0
521dc152498b8b90024bcc8aa7cf5dc48d3a90e3
1577 F20110109_AACRNI gopalakrishnan_j_Page_055.txt
9982d3b1a34a79ffa97d395447ee6b87
33b1c00c608834616a326d31ca49ab9741d8d085
1529 F20110109_AACRMU gopalakrishnan_j_Page_032.txt
23c667e263d35f9082cd225e8da7397b
019279c22db0dbca03af56327ba3cec3755a8668
F20110109_AACRNJ gopalakrishnan_j_Page_099.tif
e627d7f9bf53c8c58c8b8f3aabf5b369
0457df5449a7b4a2c618e53bf3c4eef5ca56d541
8228 F20110109_AACRMV gopalakrishnan_j_Page_023thm.jpg
244108a78a29033aca039438901b4d12
9ea5ad7c3e870b01d6496b3afb0d5055154d1faa
26125 F20110109_AACRNK gopalakrishnan_j_Page_001.jpg
c46bf22302bbc6afd95e59346d44e3cd
e208ed8082397b076f08928cae6ad8ea6e489633
8649 F20110109_AACRMW gopalakrishnan_j_Page_117thm.jpg
945055a5793b0da4be2423ca4f55370f
eccb88123194e74354304b4ca1b2c4b56f52777d
51207 F20110109_AACRNL gopalakrishnan_j_Page_024.pro
b9a34855662220ef2ff847f1d53b143f
c05e1aaa2b56dc0bdf867e09a3ab5523b0b6c934
79408 F20110109_AACRMX gopalakrishnan_j_Page_053.jpg
2879da048a4c7c63e657fc1ed665fd3d
fb437e2c51f03004af73e273da440e3d47fb9b5a
33657 F20110109_AACROA gopalakrishnan_j_Page_025.pro
0b4faa96b3b48c147c69435a4010f93e
b5089f445f62355621419419d44dab594a382cdd
1536 F20110109_AACRNM gopalakrishnan_j_Page_011.txt
8597dbbc9266d513b71b506cf02ccc1e
c9993690d70220048f70accd0a538e2989d62d9e
F20110109_AACRMY gopalakrishnan_j_Page_034.tif
c909143e3c011b0b169c6ca6959ee9b6
d47c4676df3c0f3b03802017e3f7d0a1d4a91fec
118180 F20110109_AACROB gopalakrishnan_j_Page_026.jpg
4e9efd0ca0357dd5f1fdcc46c639f309
9f759cda0b54c8bacd4ae8395d721f0812c7cb96
F20110109_AACRMZ gopalakrishnan_j_Page_065.tif
8c0fa7afe07212c603896cd41c5f0173
a09c5af51265c8c0a01b6cec1fa7516a8ad55b2b
26654 F20110109_AACROC gopalakrishnan_j_Page_057.pro
585bf86ce0a05196a3f64b5eb18fd2d0
222a34c7e2fb8f04f3999a89577c96105fb384ef
137152 F20110109_AACRNN gopalakrishnan_j_Page_081.jp2
b40417c162d6fc97b7c1c78168f60801
780e56f9be94ff4d452cb7d865c1110e13192b20
33762 F20110109_AACROD gopalakrishnan_j_Page_111.pro
1bc9b560cffe6603c603397185a5ceb0
a4e8b90b94937812faed2f407a03505199ced78f
7726 F20110109_AACRNO gopalakrishnan_j_Page_049thm.jpg
f4261dc74bf7416aefc4e0658c83f959
594e7ae67e57800c949a789b15a4deeb4ab8949c
1918 F20110109_AACROE gopalakrishnan_j_Page_082.txt
49bf812f6cea10d2d0fccc197b20602d
3b2ba1677d12982c226a2e741495dd6a75a46033
119011 F20110109_AACRNP gopalakrishnan_j_Page_089.jp2
3107133e285ae647df87115e60120659
2e0b958df971662bd3d6f3b7dcc3b207eb1b7381
F20110109_AACROF gopalakrishnan_j_Page_044.tif
fc9eeadf987b298833f9ce1c671d04d9
01506659fb04e020d836a97a87f4a91c98f080d1
F20110109_AACRNQ gopalakrishnan_j_Page_073.tif
5c50a8c1908706f98b030f122c0dc2f1
e423f9baea56f234fdf05b71985b0d9b5bf81a1d
41535 F20110109_AACROG gopalakrishnan_j_Page_074.pro
a218188279d04fa4cf4616856d3d756f
5a89f2c30baf1873aea3e4b04994a040ca9e2d02
48151 F20110109_AACRNR gopalakrishnan_j_Page_022.pro
53b3a511afbbab5fa04ec23259db11fe
6758fb379466e486cbe402bbad5c00213ca59ba6
6501 F20110109_AACROH gopalakrishnan_j_Page_002.jp2
1dfa5b74ee644afa8ae98f92779d418e
79e552ebbbc6461f404dc37124b99d59e3f49367
2898 F20110109_AACRNS gopalakrishnan_j_Page_027.txt
a43c4a0f0c2fc58acf6c5b86a7bef5d3
83816aa321a45c08bff261d6b0fdecf6b5a79cd7
1855 F20110109_AACROI gopalakrishnan_j_Page_039.txt
baf40dc1a0a09563ef5926f82d1e0ce6
be7933f89a7805ee606008f456ddbf6154a3888c
110337 F20110109_AACRNT gopalakrishnan_j_Page_091.jp2
709fe64455afa36f2b75acaa2ff71a38
b5c21fda249fed95c1ebe0cb2d4fd1061dfc9b4b
1774 F20110109_AACROJ gopalakrishnan_j_Page_073.txt
4d6bc854692cf24c81163b1d12f1033a
4bb5ce8c54fc3c4be61da5f9eb7c555f3ee9a778
1138 F20110109_AACRNU gopalakrishnan_j_Page_012.txt
3f1af29db39cade0bb2aee5ff8612473
5f3b45f6fcfe349def7d5e3f7ca6f199014608c0
8051 F20110109_AACROK gopalakrishnan_j_Page_024thm.jpg
2e2ea5a1195c797aac243cf43e3c3e1e
bfb6ec8af04922e98182a499b51eb9ebb5a343e2
31167 F20110109_AACRNV gopalakrishnan_j_Page_044.QC.jpg
05196174f140798f1931ecc9e856d994
f7abecaf2028dad0b69465238c0227243a1bcd2d
1732 F20110109_AACROL gopalakrishnan_j_Page_077.txt
ffb83b6a3444a0f0d77c18f1e4f45fdf
9bfc78b9209d67e1bec6c03486d6e5fe161eeed8
1600 F20110109_AACRNW gopalakrishnan_j_Page_031.txt
799c7611c4c13f86609bd02b4afaac3d
a18498dc9c3ead2ab87bdb8ce87f01b334883901
29865 F20110109_AACRPA gopalakrishnan_j_Page_072.QC.jpg
cae8e1f3a4caa876eafb10c1870d21f8
a0a9b801d601827b50fee79c021a31c439a4a8ae
F20110109_AACROM gopalakrishnan_j_Page_101.tif
82a354954b8838c1ea799fbb59b1da31
ebd5b0cf03d1b6be34d5689939520774afb7ef8a
96662 F20110109_AACRNX gopalakrishnan_j_Page_097.jpg
e954093d8963ca0be1d4ffef7df9428a
2096dfe70b0b337c668bb51cc23118b0b9289cbd
129191 F20110109_AACRPB gopalakrishnan_j_Page_117.jp2
fa677ec2cfe2c9763225cec66c28886a
a2739db54baadeb1c9d8767d1190d509a2e323a8
33667 F20110109_AACRON gopalakrishnan_j_Page_048.QC.jpg
12db9cb2fff3f4f8f1c109fa34c6429c
fa5d6ac3a5bacdc9539627c55d232ab33d6c5131
F20110109_AACRNY gopalakrishnan_j_Page_025.tif
ad2f667028c4a1cfcdca47bc45ca2804
895c64cee9f48419d9696d0626d4bfde4d880809
91142 F20110109_AACRPC gopalakrishnan_j_Page_112.jp2
e8a7e308a9717eb9f2c18e4c3769673d
abaa52bcec4f00fcb49fd41b49715a5bfce1ae6c
90852 F20110109_AACRNZ gopalakrishnan_j_Page_068.jpg
0b98cc255881478763c0f0ca58265caa
b452931d2cd4010eb37f90dda705105ecb5fdb1b
1716 F20110109_AACRPD gopalakrishnan_j_Page_115thm.jpg
86e53dabeead51bf97a9297557aa6db3
e73808a61f755857d2ee54332fe13d9cb024ef10
F20110109_AACROO gopalakrishnan_j_Page_108.tif
4c5144127e518b34a171fcbfd5136a7e
a7c10873bce03a4977be6d0844e4032de4eb16c3
7691 F20110109_AACRPE gopalakrishnan_j_Page_101thm.jpg
6a14abbecc9ef4edd6a1049cdf299bdf
df75de5b8b3d5fa06c3a03e958fb401fbdb2894a
7758 F20110109_AACROP gopalakrishnan_j_Page_056thm.jpg
5106b20b4b2b640e1ea30908c9944367
23a1e45b5c4b0d167f82285103a16e250b6c9340
2303 F20110109_AACRPF gopalakrishnan_j_Page_048.txt
f5e3f8665f4a8ed2d9744f64d11420b0
26d048c3256ffd0c6195a09f3322ac2340c66e4f
32721 F20110109_AACROQ gopalakrishnan_j_Page_075.jpg
f97fb570bd9f8d0478ce67e1804824f1
ccb2c1d2fabd483713a551cea23717f21844fb47
31341 F20110109_AACRPG gopalakrishnan_j_Page_006.QC.jpg
4319896150fb94c0bf03cb068dcbbe60
2d2019f01aefb37da03c68efdaa6fa2bb05a9397
42507 F20110109_AACROR gopalakrishnan_j_Page_058.pro
47704e5ee37ce6a17512923285afd465
b694112fadda65fe7b7f313920dc7ec8704eaf6e
25856 F20110109_AACROS gopalakrishnan_j_Page_017.QC.jpg
4f40de1aea1e0477c81547bedb95512a
0e24c14ac4dc3d809c25099457ddda41ecfa810c
64770 F20110109_AACRPH gopalakrishnan_j_Page_057.jpg
6092cb2d8792ce6a6b927f99a2b2c9cf
c1fe043c1b559cd834f767d155d86dfa6ad2e787
1800 F20110109_AACROT gopalakrishnan_j_Page_018.txt
97ce74f6fd21d6c23db9dbbabe0264e1
8fdd563010aaf29c98aefef2c7cab75042b116bf
40192 F20110109_AACRPI gopalakrishnan_j_Page_103.pro
2295b4067a9a2e8c3deebe53b1bf8e6e
6fbe4a263d48c88c02ac8ac9e16211b137de3f20
65786 F20110109_AACROU gopalakrishnan_j_Page_063.pro
1d2130976b084a7d3040dd1db8041206
432986d6f48b296b30986e5bbdcae9c79554bb9b
1299 F20110109_AACRPJ gopalakrishnan_j_Page_053.txt
d436a09eb5e43907212e6c95ded86a4f
5f1e4a0e13d645eb610ec33e975c11627d0bf368
F20110109_AACROV gopalakrishnan_j_Page_002.tif
23da6a557337b89de002dcf8f8ffa690
90fd00b8bf3261410b4a0f9e239191a44883216f
1676 F20110109_AACRPK gopalakrishnan_j_Page_074.txt
1bb27243844ff78eda04e06a2cbd5066
2824fadc01a2c80d175a085812a43d9b5a9b3768
32271 F20110109_AACROW gopalakrishnan_j_Page_007.QC.jpg
336b94919679e30df3a568302d22df2e
02733b476b5b4f8ef0026bd80df37c49fd818f74
1832 F20110109_AACRPL gopalakrishnan_j_Page_078.txt
1af60199fce426c2906f59a8b3427bbe
552d680126e6cc8ae7aed31641577829c074ab26
F20110109_AACROX gopalakrishnan_j_Page_030.tif
fd0727a0207287456a5e07cc066970af
10e2d437a84afee552eb72029e7188a7c1616ff3
17941 F20110109_AACRQA gopalakrishnan_j_Page_105.QC.jpg
23dee0dc96d898622e6ba5200b4dcf3f
732937ed02d10108e717e6575fdca781ca1a6129
28713 F20110109_AACRPM gopalakrishnan_j_Page_039.QC.jpg
71ba5ad95320bab69473dccf11d75a1f
48286c97b12c86109eb5dc362549498b803da7df
94881 F20110109_AACROY gopalakrishnan_j_Page_077.jp2
828838c51c431453498f5874ba047954
f98e1c4f24e787205265cc100d267604052e9d23
F20110109_AACRQB gopalakrishnan_j_Page_015.tif
99a78f4f9c693bc051614d16b515efea
b3a3f679eb01919da49ecf2213cebacd2a6d0eb1
8670 F20110109_AACRPN gopalakrishnan_j_Page_091thm.jpg
775fbb8169b42a21f9650760fffb4cb6
d12d1bc6aa3707414cc1fed2b8c6cc0ab080ff1e
F20110109_AACROZ gopalakrishnan_j_Page_043.tif
62a33bd5dcc4a98dc091fd4ee36e382b
25011389dc671cdc4387e82e52a866f55af6c771
90011 F20110109_AACRQC gopalakrishnan_j_Page_049.jpg
635a9fc1213409c60a6d75aef5e18933
2a9ccfb230eb74af3ba0d9aa6ee4c02f1446e6bd
33399 F20110109_AACRPO gopalakrishnan_j_Page_026.QC.jpg
0d7a3ea96879ea82e62257bc9c6f1f2a
a46457010accf5ef4c5871924314ea53ad8c2cd6
39407 F20110109_AACRQD gopalakrishnan_j_Page_095.pro
18721477650b645a52274bb07d67a2ba
f10e787e106fc2087fc4a14b4ff143de325c94c4
44784 F20110109_AACRQE gopalakrishnan_j_Page_039.pro
69e3f2fd9723d2d892919463c3fcfeae
71511daeb01c01a28b73a2ea36ec805e6d771d68
132942 F20110109_AACRPP gopalakrishnan_j_Page_080.jp2
df73c3f33d5880afe31f4571e8b4f4aa
0323c95254065566fa27c8a77ea97d38c83924ce
99471 F20110109_AACRQF gopalakrishnan_j_Page_118.jpg
dd5a95968bd4baa939f85dedbaf107af
2ec4b50cbc43ca297a8cc1c85824785d44c43685
134060 F20110109_AACRPQ gopalakrishnan_j_Page_063.jp2
9fd034d2d485ed5731d3407676bf9d5f
122c8c70dbf2dad2a0b7f5b633dab41faca17805
6043 F20110109_AACRQG gopalakrishnan_j_Page_057thm.jpg
a8d8ba20578efbbe97fb033896c55df2
9fddee21023c420b89fc816908dc0be105b5a025
97307 F20110109_AACRPR gopalakrishnan_j_Page_100.jpg
8eb94be44ddbfcf44aaa7e9610e648ee
f04d86422f2bf41e4b80215502f7edff94191496
34989 F20110109_AACRQH gopalakrishnan_j_Page_061.QC.jpg
42d7e3330fa60a676afafffac6998ff4
f3252cf614126f165838b56d30069d866940f06c
86155 F20110109_AACRPS gopalakrishnan_j_Page_079.jp2
073f09c8c4ec3b9c80010d27a2a32bf1
b29e49e631f21857d0747a0b1f6b84f1934a44cd
36509 F20110109_AACRQI gopalakrishnan_j_Page_027.QC.jpg
23b4b92805befe2159ebdce3a2586421
3fd7666f67845c93ed8668fb61d49ce607911284
35679 F20110109_AACRPT gopalakrishnan_j_Page_064.QC.jpg
d33fbb25367b9398ceeb7ab87be7a1a5
1d7387d1b8797d84a42b9fbdb6513e64109eb777
92004 F20110109_AACRQJ gopalakrishnan_j_Page_092.jp2
7ba2c3f5f0ea4a609af8bf9a14ea75f4
71117c8c9494d70cf370ab67b8a7e949f614c749
106564 F20110109_AACRPU gopalakrishnan_j_Page_005.jpg
2b1ddaf808a60464ca1fa1cdf2291092
1917c98dcd4be8871d21e0bbed75d574a85b865c
74964 F20110109_AACRQK gopalakrishnan_j_Page_106.jpg
9e85606daa8beeb3048886edb6b045c7
b09815d84c3e240fba722bc818d57b5d1b611772
31490 F20110109_AACRPV gopalakrishnan_j_Page_088.QC.jpg
772348f8bea915161f3bd600fff66446
bd09741cb931c797f729cfd09e69c4cf447dbd49
1283 F20110109_AACRQL gopalakrishnan_j_Page_098thm.jpg
be6560c0683baff1c428c6eca7059a48
8ceb1e44e30ed507f00d9d523708ec6da6d596f6
3235 F20110109_AACRPW gopalakrishnan_j_Page_008thm.jpg
7f0f3504911909a0d2864677854bf5e3
44beb73b0d9ad76cb93973f0290020669b22da2b
31851 F20110109_AACRRA gopalakrishnan_j_Page_066.QC.jpg
d25f7ad10346a72ce4c9fd4a69977705
50405dbca2624c8e5cb97d4adec63ead2154b147
F20110109_AACRQM gopalakrishnan_j_Page_091.tif
c45184a18f8c98d3b3cb4cd2a491748c
ceaa7a0e71acfd70f3abe1293f48e161b6ada1a2
26568 F20110109_AACRPX gopalakrishnan_j_Page_059.QC.jpg
eb2ab84634baa3c6658e4450eabe6752
bdf2d405fd25111d91fc5a65e3094b0ec9b66dd8
1812 F20110109_AACRRB gopalakrishnan_j_Page_108.txt
2cea65497bee6bc95451ae12b8135ca6
4cc5f823d1e9dbad412b43dfae5d525fc7d3d3a1
1828 F20110109_AACRQN gopalakrishnan_j_Page_042.txt
37a8d5f25d59cbb2ceb382c5c0b01d4d
a5b8edd50203a398d4402cbdb1f2e10c4c0abb68
F20110109_AACRPY gopalakrishnan_j_Page_093.tif
01479c90ac7da7f46ec306d0b824db99
3e3bb34a4db3a98ca086edcede26bffafad382df
94748 F20110109_AACRRC gopalakrishnan_j_Page_054.jp2
770420be86c5e9b221cf3f40d43616cc
e13de8c21772fc45a97ba568d83f73ca00fff467
102173 F20110109_AACRQO gopalakrishnan_j_Page_078.jp2
9cb457916390ca192548c6a69317616a
74c12cc925e9184cb6b6da0853eeb0628a64a114
89460 F20110109_AACRPZ gopalakrishnan_j_Page_033.jp2
6e9c03780e11c58fcfb034fcd23a6fc0
3981a2d1bc31554221f922702fc6d8a379c04caf
692844 F20110109_AACRRD gopalakrishnan_j_Page_057.jp2
4b2880a6dd18fa1a3895f524c082d065
fea8794069df8d7076ece26c0d1e8466500c3fd3
F20110109_AACRQP gopalakrishnan_j_Page_016.tif
5fdc8eec602c3d336e5d5f701143ee87
ca7fbd87232298f63aff3d2a7b81195801e987e4
2504 F20110109_AACRRE gopalakrishnan_j_Page_021.txt
87907e54b264cb3993012331be1b3f76
4ea6c14e228932bded35bf570008994d598f7ad3
91685 F20110109_AACRRF gopalakrishnan_j_Page_039.jpg
a8f0490a3f31c36a0e1b5f4d2fe8dc37
c1c4b07b73b5f5b5290255746657e6a0699a102d
6743 F20110109_AACRQQ gopalakrishnan_j_Page_029thm.jpg
524701b10a23d8d2f4fdf33fbf94c55e
1ca1f26f0c9bb45d47e2e8b2a78a0ff542f747d6
73899 F20110109_AACRRG gopalakrishnan_j_Page_082.jpg
e6f40937dee0c30c55fb6f6411dcac93
571fc388cfa64d56bfb2df586c668a2a0d6ba21a
1683 F20110109_AACRQR gopalakrishnan_j_Page_054.txt
0ef7cb71fc53bbd21e6b8f788f052131
267bbb5045036764eea0f6e2aa6dfd26ba6dcb7d
29169 F20110109_AACRRH gopalakrishnan_j_Page_041.QC.jpg
15705c1e33179b49f87f99e81887b757
72d20eb0b4f8cfc5e3af69ae32a911bccc8f91e8
20412 F20110109_AACRQS gopalakrishnan_j_Page_119.pro
70eccd709c3b0c77f8b46c830ecd6ee3
08b8f746e9d0c1491af524ba53ceb839873aaab1
56377 F20110109_AACRRI gopalakrishnan_j_Page_048.pro
12e236742b51426a33e6d4158367d4bb
4fece4c1b025ec6558ff0d0424d662e5e3bb8cd0
12500 F20110109_AACRQT gopalakrishnan_j_Page_037.pro
f4a2faae3ceb8d8fef0f428d9128848b
40457e0560a3faf9d37e12a6489f99917a5ef26a
8426 F20110109_AACRRJ gopalakrishnan_j_Page_048thm.jpg
e42b6afb62e3b6d3fb119cc9f1ee9b93
3f2e1c54bdd6cc6003db040c74b8d1d17b883fe5
45296 F20110109_AACRQU gopalakrishnan_j_Page_101.pro
8142be39e8776fdcbc2b1dfbf7979395
02878b0264c03ae55441bbd32d0b0e718137a930
7618 F20110109_AACRRK gopalakrishnan_j_Page_068thm.jpg
e68d1cfb449fea28cfada36802057a64
b907a5650b8ef7b1a1d007a3cce3a17ae8a7590f
8044 F20110109_AACRQV gopalakrishnan_j_Page_021thm.jpg
af684105318a3bf126c06717aec1c8d5
4bfa11ddd154734a5963747d2c5236c59880724f
62073 F20110109_AACRRL gopalakrishnan_j_Page_117.pro
471f1b30aef8885636a5d26ce8aff7c3
a63c2344f9e63dc4a91c80374f273be9abc444c1
F20110109_AACRQW gopalakrishnan_j_Page_102.tif
25f6efe873b705ae7d2454cb2dabcd4b
5d1ac07e20e65f6132c24c17d7d86bb4181c0414
88751 F20110109_AACRRM gopalakrishnan_j_Page_094.jp2
f94064589b3a840646f39a534d5fe5e8
7cbb1a262fc76c9fb313b098f516e30bd4393dc2
24920 F20110109_AACRQX gopalakrishnan_j_Page_028.QC.jpg
163770110c11f74c63c19fc65afe4433
e67b42e4da8af14af91e28acc940412e5657629c
90963 F20110109_AACRSA gopalakrishnan_j_Page_112.jpg
7ded424af028e6719a140b03a1e1d774
a0b82b2b518d6dc1d4ed1bf0aa66789e81b1349f
2161 F20110109_AACRRN gopalakrishnan_j_Page_116.txt
70fdd894d7bcf03fc289833fdc5530e5
1719159a5f9b9ad8c9df69c17edc4b7dad89c001
1051979 F20110109_AACRQY gopalakrishnan_j_Page_010.jp2
ec6602e784176abf72d8d8338d53f4af
12fe4e6fb7296c98cf7c196e3fdd5c041461c06e
102298 F20110109_AACRSB gopalakrishnan_j_Page_022.jp2
b25a938e1db60051ebf54437b180d99c
a126fb1a681dfbeb305d4b6f229af1ae3f50c83b
86786 F20110109_AACRRO gopalakrishnan_j_Page_016.jp2
5d66611d61ee19a8b18ec95a8c5d1953
c312ecfc2ab53a63cd9eaeee9b6c8b1b092b38d5
47424 F20110109_AACRQZ gopalakrishnan_j_Page_014.pro
16aa0073b821425f379ba1c88a344a34
64262ba46f559c66cd8543b38099b93f364728cf
102550 F20110109_AACRSC gopalakrishnan_j_Page_118.jp2
de6fa6033b3b89f58d994b17340906d5
046072ba9463b247b9fa0027afd9c0ecdbef8367
1883 F20110109_AACRRP gopalakrishnan_j_Page_045.txt
3ae4e4b6bf828f18ed01aa11169868fa
6a65cb51d0951a3ac84ae4aeb083a4857e3ae18b
60057 F20110109_AACRSD gopalakrishnan_j_Page_012.jpg
044d481b959036a448f3170377aa3f21
9726b898ee8e491400fca93c6d504c4abf82924d
52036 F20110109_AACRRQ gopalakrishnan_j_Page_116.pro
dce8f22f732e82cb34c24e223af2edbd
0214b03a018abb27bf5815f2b0e7d368096a8113
F20110109_AACRSE gopalakrishnan_j_Page_060.tif
bec14701df8975068840391fdb1551e8
a61d0816df90a1953610bb2496c33e9223cf2691
F20110109_AACRSF gopalakrishnan_j_Page_052.tif
3fda56e74787567db2b291ac27f1f5c7
8142d15d6965330c97233b74ff8549de88231877
1669 F20110109_AACRRR gopalakrishnan_j_Page_033.txt
b009c5a4552f0bd2191df141b900d048
8e1926a95d9dc3b205678e92b53eb432741bfbda
28590 F20110109_AACRSG gopalakrishnan_j_Page_013.QC.jpg
a8c20710191e08bcb425a38144015fdb
1b3d4ec85013579e28af068200a4e7b4e7fccad4
F20110109_AACRRS gopalakrishnan_j_Page_119.tif
87af1f5ece3074c4451074dcb6f94c66
c461f8ff3c60b0d2fe5f7b0a288727f3926d1ddf
8654 F20110109_AACRSH gopalakrishnan_j_Page_036.pro
f0109e2e292d48343e012c368de1a541
d4ec4a477f5bf876f20f4366db6a30aba84d495d
951919 F20110109_AACRRT gopalakrishnan_j_Page_028.jp2
37c51daeadf7b1f3df8f7661066e0db2
c6c3b0bc514a238807ab9cf94ebf54b97d6a25f4
7717 F20110109_AACRSI gopalakrishnan_j_Page_001.QC.jpg
dd39078dcb4bacdea9250cede83e22db
936f9f9aa07ba5d7edb6e487754f13d5dd0b81d5
982 F20110109_AACRRU gopalakrishnan_j_Page_105.txt
f2bf387e27f3919d18ab8570e43bd86d
f6558381e88d191391bc90d0912bdb7b4a9d79e8
F20110109_AACRSJ gopalakrishnan_j_Page_013.tif
97a9d04a0bde34f2825b399a1564a3b8
1a5e32ed3b68ac03f948d97ae539598777630bf1
804420 F20110109_AACRRV gopalakrishnan_j_Page_047.jp2
76454e506a32091ee8ecb2073d96770a
a9122a0d9df67d62e0dccbe29ad5053fa2e628c6
F20110109_AACRSK gopalakrishnan_j_Page_045.tif
f1b60903ccc8d2ac083eb7b1e0219ae9
20bf1a534dec9ce98b912b74e2414268263aac80
106282 F20110109_AACRRW gopalakrishnan_j_Page_090.jpg
9fe5774d0c4f7d1a8b830ad3f172d26c
d15cb27f378538a2ffccda12a8edd6e3232a50ff
1562 F20110109_AACRSL gopalakrishnan_j_Page_025.txt
c3d28fabae884c8ccd23f9b309caeb3b
f9fbdd270f9b6d934c076229d1842255b410085d
95224 F20110109_AACRRX gopalakrishnan_j_Page_042.jp2
92d3ee76bb273a2b890d47f12801e38d
37bf2b63cfc2d799402504281c4511f0e474e02d
96100 F20110109_AACRTA gopalakrishnan_j_Page_013.jpg
64ea5ae1c0c0bd906f85ef3ada1c3a70
62ef82c05c4d3e62e528d8c45981f23891091acf
F20110109_AACRSM gopalakrishnan_j_Page_017.tif
89cb9c589946221a9a7ad6bd780a2784
2ad6f1448231230baadb5afa2b6d9778b7131b2a
18609 F20110109_AACRRY gopalakrishnan_j_Page_004.QC.jpg
ba98c052003c9e2a142c3a39860eb487
01c4d4af1fd7b5f9ef23420477b687529350bd0d
12183 F20110109_AACRTB gopalakrishnan_j_Page_038.QC.jpg
79617cb3fc82242597f937a32bab4546
680ed7ba5d44c758c5c7b3a1d8fbfecb760d7972
96343 F20110109_AACRSN gopalakrishnan_j_Page_102.jpg
d07d20dd8d8edf1b31f165136cf81809
3d4e64e57ec827857da54d7bfdd16b026102904a
92235 F20110109_AACRRZ gopalakrishnan_j_Page_113.jpg
89e4a10f0eb7da017208a68c625c00a1
d2d2dc6f04745b9d975f6f46eab2027a9a62ecad
49242 F20110109_AACRTC gopalakrishnan_j_Page_066.pro
d296e1e9a5e142b361decaaf557d4990
a09b80cab77b5a100075704677cbd9ea98b11402
8423998 F20110109_AACRSO gopalakrishnan_j_Page_082.tif
287deca646d2f43659d805ad4e75f801
5f18c5fbd7bbbf55bf0b75ecd8901a2fb830e728
8732 F20110109_AACRTD gopalakrishnan_j_Page_027thm.jpg
96291a5a1346c417f198fd3ffb268d84
c21d7b07bc5eb85f4b6340b5fa4085fe27bac86c
45043 F20110109_AACRSP gopalakrishnan_j_Page_100.pro
b19cbb51b244a43e6c676496084922cd
0fd9e4618d0a506c334831e1e313c6c483c2ea03
F20110109_AACRTE gopalakrishnan_j_Page_079.tif
8cd6ce1530e88f13949f3abe53fc1830
ba74ef6d904a237079dab02c440d8ab99f36d2d6
F20110109_AACRSQ gopalakrishnan_j_Page_010.tif
906b3859962b55990d9c800ddfe85669
aae969896b5a2398ef6f54dae46d56adffc6ac1b
131350 F20110109_AACRTF gopalakrishnan_j_Page_081.jpg
1def6378d0fd1f0a2b12a086072a0ba8
0856590414f3348409cd7782ba624fa67f892126
1826 F20110109_AACRSR gopalakrishnan_j_Page_015.txt
583ef00893cd229688d57f62505d102b
a5a87c75b2fa4346d69cb2827d879eb22ff06ee6
F20110109_AACRTG gopalakrishnan_j_Page_031.tif
045706f4cc832cec8b425413cd8b3d4e
3262a733664cafb9248e604600abac5c6e9b933d
7505 F20110109_AACRTH gopalakrishnan_j_Page_104thm.jpg
8a4f28eec2ad248acaf3a05d4ae929eb
c199eb67d3799c6ffb156cfefdf88fba85fb869c
90308 F20110109_AACRSS gopalakrishnan_j_Page_041.jpg
192c9871e34bf1063097883cad76c221
8cbd140d18835bb7499cecc81638defba17aa872
77966 F20110109_AACRTI gopalakrishnan_j_Page_109.jpg
757ff35ce37ae9a97b799014423fa4db
a48502e49f7b57bb2d1f099654044cddf1b9a79c
114912 F20110109_AACRST gopalakrishnan_j_Page_048.jpg
01fcb0aa1358785d20cdb9d8bf0d8f96
08bab807059384317bfc712040de0cb2182e3395
29206 F20110109_AACRTJ gopalakrishnan_j_Page_033.QC.jpg
afbd25755d71ad429189afb114800b8a
e0016146fd79ba2b866ddebf3fdbeb0b29d1d928
F20110109_AACRSU gopalakrishnan_j_Page_111.tif
5abc3bbc39eaf5121729343cbca84e13
c2f95bd23c78a89eb9ceb15363d1b31d818de83c
57630 F20110109_AACRTK gopalakrishnan_j_Page_071.pro
b71ec2c5412830cfec762209f4a575c7
bf980b352b031e7932b3a943a92e89a0b9075b1d
F20110109_AACRSV gopalakrishnan_j_Page_024.tif
22ff02d1179fe614ba21c355763e6f98
ef03c4284017203c76ac59688de4ec42daec30ca
24476 F20110109_AACRTL gopalakrishnan_j_Page_047.QC.jpg
b5e5f4f09eb24bbc055e584a19fd0cad
eb5834bf4850bb524268fff649597b2ed7a7b180
98242 F20110109_AACRSW gopalakrishnan_j_Page_084.jp2
b4e596199980b5d835b9e62f8e5581d2
6ad5d0e99018f22b1c7a09589cb0af0254c350e9
98537 F20110109_AACRUA gopalakrishnan_j_Page_086.jpg
84b0d272c0f2de1021de3a0f52171531
3483c78461390cdfe24e1dbf298e2504640c091b
46221 F20110109_AACRTM gopalakrishnan_j_Page_078.pro
568eb5ebf2264afccb435246bd52dfd6
e1a8edb4fa7949265e57389c7ae95069173f7c06
48186 F20110109_AACRSX gopalakrishnan_j_Page_118.pro
c3be2c64f6e042c027b18bca5e14f8e1
5a0e4fcae587511581fc23bfec9b6c4e9d56fe10
32405 F20110109_AACRUB gopalakrishnan_j_Page_090.QC.jpg
c902424572df1550a0921380bb2e33dd
11dc98056b81ae86c0980045d604128555e0a348
29842 F20110109_AACRTN gopalakrishnan_j_Page_022.QC.jpg
c7f9ef7e7168a28ab80750605ca521df
45842c4f04b25565fb64591ce576215db904f29d
F20110109_AACRSY gopalakrishnan_j_Page_048.tif
124d628d0ba9e814a30dd392e514e924
9e47bfdd55f036a83cb286d0d1104ed6c187862c
89852 F20110109_AACRUC gopalakrishnan_j_Page_067.jpg
985897570bd0ab4d7e2c1416aac10742
2e54635438dace10e6c4661f859e951b942d9ad0
39145 F20110109_AACRTO gopalakrishnan_j_Page_094.pro
bbf40a4f69101dcc71fdbb8932df51f6
3d0d067acb7e15d66ebeffc10fc0267cd68ea64d
1895 F20110109_AACRSZ gopalakrishnan_j_Page_013.txt
4c505b7179493c5e5e6cde84531aef0d
a2e79937720a336c727c6153ad47a3607167fd9b
F20110109_AACRUD gopalakrishnan_j_Page_024.txt
98092bd74b73fd73a12905c1bb59a1ad
e4b7dabec2b439002fa74f44cde3a7abf4dc837b
7722 F20110109_AACRTP gopalakrishnan_j_Page_095thm.jpg
e1c9624be53f5f69b6497cb6df037bc0
3d4c03fdb436e0207b78dcafaf200835d0c4e2de
7045 F20110109_AACRTQ gopalakrishnan_j_Page_030thm.jpg
21c42f9fbb814fc1bf6e9deaaaf890ad
293e8dc3c5942e362cf36b8a44328697fe7f1c68
79341 F20110109_AACRUE gopalakrishnan_j_Page_114.jp2
2e148375eebbd69c882df84f0cd5872e
58c196c5f3b6ade3d37417401b23fe9e531351d5
28759 F20110109_AACRTR gopalakrishnan_j_Page_051.QC.jpg
04b43b03ed898cf66c69f2a4c407e866
8b26ffb8270842c6924c82eec1a66838debeee4b
F20110109_AACRUF gopalakrishnan_j_Page_064.tif
aaad6bb52fcaa3f45aaa94a21780e5a6
cc4a0202a36b62470553c883ccd2f80a72919b0e
224 F20110109_AACRTS gopalakrishnan_j_Page_050.txt
6742077b26ebcc4c9912e1807804fbed
7134533b66d188245f3048561a97540e6389e92e
85260 F20110109_AACSAA gopalakrishnan_j_Page_055.jp2
91ba260bb8f3983aa8df996c356c34a0
07ba30723eb810710f551ebb7e4d7443c8aa0afb
818321 F20110109_AACRUG gopalakrishnan_j_Page_025.jp2
a935a9b2899c242cf2cc50ee30ee5441
0d301186fd3845b2ca6e82740001a19d41dbfc44
32178 F20110109_AACSAB gopalakrishnan_j_Page_023.QC.jpg
123ca10c6e475e61b9c6c6675513299a
ab9d3d7f9b2b0823dc896b1e03b29f5cea967a72
45948 F20110109_AACRUH gopalakrishnan_j_Page_088.pro
5c497914c56ec749e5832ef0fd779b76
8320a21fc54df6ca4c5691029ed4d52b2fb430d5
80128 F20110109_AACRTT gopalakrishnan_j_Page_108.jp2
4ed6ace65e49674a3308bd53749fa428
4bdd938b57721785c9bef8e1914935fa17ee6eda
6875 F20110109_AACSAC gopalakrishnan_j_Page_082thm.jpg
a5558897ee61c3f7fdfa6a361b689e04
08ba72e33c39175b1e5cac380a3d225d20008224
1712 F20110109_AACRUI gopalakrishnan_j_Page_079.txt
f928e2d6867cef67d8d95a5e301b5246
6ee8d075bce567893843571a9e243f1e88255c83
102349 F20110109_AACRTU gopalakrishnan_j_Page_014.jp2
eb1e838bb808861f530053404f52654c
6fe9a7bec89272abbf510ecc0e4f4d84a5829ba4
1861 F20110109_AACSAD gopalakrishnan_j_Page_060.txt
bc5442cb09d6ea30b9ba901726cf7114
e9d27d6eb558224082a4b2441136bc8a484124c4
F20110109_AACRUJ gopalakrishnan_j_Page_041.tif
d272bbed12e220472e5e2538de3812fc
d06d0e9c939c7ea7bcd2eb2d560ba03f609d2b57
977687 F20110109_AACRTV gopalakrishnan_j_Page_008.jp2
73770fba94cb526f6e586759527cb781
6db151cda7e5536772149fe322471d9a9e013712
92094 F20110109_AACSAE gopalakrishnan_j_Page_018.jpg
13cd2e5d90f9e99004d947b6e915f9c8
4c83e14b4b2200ad042c896a2f9bc7b5895cdc80
1813 F20110109_AACRUK gopalakrishnan_j_Page_114.txt
bdc7304d02f093a5b90b9b8625a8d560
bae34ac5abc2bc9650e5c11cc0472e5a8f18b47b
F20110109_AACRTW gopalakrishnan_j_Page_001.tif
8f1fa1f537fbc6cee94deebc2fae39fe
d0b11568e8a1eb732545fe6701432218734f907d
F20110109_AACSAF gopalakrishnan_j_Page_104.tif
8db9ee05d37ef695ac86fdd893500c5c
73b6f8a7c4f157fba3b2688a9012985956bc4366
97012 F20110109_AACRUL gopalakrishnan_j_Page_039.jp2
c5e8dbc9466c7c6a329579855701d7bf
639869e4754862d87c6e99f732b270ba719057ce
83555 F20110109_AACRTX gopalakrishnan_j_Page_103.jpg
a2fe4a0a06bfaffe42d2bd383050ffe3
d26d0b0abd93084a25c75816e2ded251f5c51a4b
F20110109_AACSAG gopalakrishnan_j_Page_033.tif
394d452d21bb012d51b9077da604e48d
d652036dde4accf21bd387ac8790d4de9ca78a42
7831 F20110109_AACRVA gopalakrishnan_j_Page_096thm.jpg
04f2dc20a6ecd7b49dede7e248dbdcfe
aec77e5d1fc10bb3a01eb3a463abd9e3edfbf6c0
45706 F20110109_AACRUM gopalakrishnan_j_Page_013.pro
f283942b1a0d26bb6f097ddddeaf787a
e48997cfb49c13c4298f69193cb5e0133d529b42
30171 F20110109_AACRTY gopalakrishnan_j_Page_096.QC.jpg
98284737ea37cf2e9654d8674e2b48b7
c48cd548d56a509ff7601a3fe9fc70cb4c1d622e
F20110109_AACSAH gopalakrishnan_j_Page_117.tif
1de0093d082d1e26097542a84725d16e
d8bd7ce5a72a935d5c41a58a683c5a669e0f2929
7588 F20110109_AACRVB gopalakrishnan_j_Page_115.QC.jpg
8e52bbd37f29a26974911b5030c88d09
4da38c2b300028463824eb33f76459a039daec92
1775 F20110109_AACRUN gopalakrishnan_j_Page_092.txt
55d0fb8cbaf59e40384459d57a907182
a9b061d37ca40b3207fab429885c661e6109b356
94894 F20110109_AACRTZ gopalakrishnan_j_Page_051.jp2
b35ccf31bbc72e919e61d4b1d229b804
db5ea192c2ca557be34e893d04319f861cfcdf42
3313 F20110109_AACSAI gopalakrishnan_j_Page_043.QC.jpg
63e7fb3512833a7ce573698e05ad3ca9
e312f82e4cb583bf186fbd1a1c1aef2dc7f80aa2
94733 F20110109_AACRVC gopalakrishnan_j_Page_113.jp2
3565248aee32d15b69a849537a4a8647
44df7e80f44d71e2b7d6133d371e682fa7208f32
7481 F20110109_AACRUO gopalakrishnan_j_Page_058thm.jpg
f63fdc3ea208c180202239c07e03b4f6
0ef47307604379c7de83ed9a81403bb3f031bfc7
3930 F20110109_AACSAJ gopalakrishnan_j_Page_038thm.jpg
fb763e5f297144d8e843c3489f7267f4
5f69c6d6800848cabe00a6e1d3143299da47dd42
101351 F20110109_AACRVD gopalakrishnan_j_Page_066.jpg
0b2a8b650dbab1e956f7a361ccca5466
23e257cc4b3ea4a1e8c75bb47113d9c15360f01d
F20110109_AACRUP gopalakrishnan_j_Page_028.tif
201286ab92922bb7b5ef2cd9ca3ede05
3960fd63c0237a78a7393f78626a0629da6768bc
51263 F20110109_AACSAK gopalakrishnan_j_Page_070.pro
d432dec39368dae124d5518927f5a2de
78a201e57b6f805dd170c9fedbc5f9a48b138848
89467 F20110109_AACRVE gopalakrishnan_j_Page_087.jp2
bec6e9a5a242e28a6d92536486d99b86
3447ce694a5fcb59af1449c2c07d80f91c0b77af
2044 F20110109_AACRUQ gopalakrishnan_j_Page_069.txt
005572b2b15b269609330fb0a9ca0dae
2a1f5eb5b468b504ad69a37d84f01555f9f39f48
31765 F20110109_AACSAL gopalakrishnan_j_Page_056.QC.jpg
d26506aa9eec2457a356ab116e790072
ff7f821858360f1df7a1708e63093b8ccce19d49
102877 F20110109_AACRVF gopalakrishnan_j_Page_070.jpg
2bdd76f855e94de4c88690abcf1f9327
e8af06447052960cfeaf2f87e6957b606ceb8de9
32279 F20110109_AACRUR gopalakrishnan_j_Page_045.QC.jpg
8e18d245355b540090f0f80b732d2b92
7a981187acf19d1a50fe34c68a121ad53f78d05f
F20110109_AACSBA gopalakrishnan_j_Page_050.tif
53f766856e2c0cf408ed3e8e1b2f11bb
60397e8087782a624cdffd5fcaf910166c6e4c7f
F20110109_AACSAM gopalakrishnan_j_Page_021.tif
cd647a3fa94f566a8a5fd4b69dc2aee3
210ff8f427459c06263ae22e2df985bcf0206567
102782 F20110109_AACRVG gopalakrishnan_j_Page_056.jp2
50273cb60b07cda11592e4e609b7490e
5b87c13eae1f948fd1b463355f189879e3ea0b08
30506 F20110109_AACRUS gopalakrishnan_j_Page_082.pro
0e0255bcc3476b85055a15f9cb2294dc
30788faba5831b346fb86ee4df8136f48ca03bb7
50593 F20110109_AACSAN gopalakrishnan_j_Page_065.pro
9222dbd432563de0c3964f8ed8ec0bc4
f71bca0a190ebe7943539a583da5d5aed6021f44
1802 F20110109_AACRVH gopalakrishnan_j_Page_101.txt
30832b6b5ee4e301fa4fa64c2b38ab59
f315d7bc8c942df63e3e18082b806fd4c7026e99
2219 F20110109_AACRUT gopalakrishnan_j_Page_001thm.jpg
f8af91ae4996108f414fb0c39f0d5f8c
f69efd285e5b25da9dfd54f9dfa49b1b5c09c368
40460 F20110109_AACSBB gopalakrishnan_j_Page_109.pro
ec8a7b4377ebb277a16cf91699989f57
f1a10df16a914a846ce620e4284eb9a06ad81a25
116813 F20110109_AACSAO gopalakrishnan_j_Page_021.jpg
5ecaf0e95892da040e8cee476b6ec270
7de6c46f116a9f65770b30d96aff16e656b12790
33463 F20110109_AACRVI gopalakrishnan_j_Page_037.jpg
6eb828a05f2df575c8a3ce9ab5ea3e7f
1da19933c9a5161334c6a43ed0944de79df05c77
48338 F20110109_AACSBC gopalakrishnan_j_Page_119.jp2
030356b6eb64eb0278e8ef3c46a789f8
9c305b3501adf8df770bbb854d27592931257493
5918 F20110109_AACSAP gopalakrishnan_j_Page_106thm.jpg
ba9a1cd23f0591918fb5710373d35e41
d4e5ae22d0dc07dd88546dca4dfbe1c3dd0d6806
25730 F20110109_AACRVJ gopalakrishnan_j_Page_062.QC.jpg
b4567d827dea68409c9de33dda3b4905
16e1c301643b1481e143814e918d7b5efe45486d
F20110109_AACRUU gopalakrishnan_j_Page_109.tif
aa47815255f7750c55b9716ee9d8ee8d
9002a14ead88cdc56fcd05c1b5db83103d28bb6f
F20110109_AACSBD gopalakrishnan_j_Page_118.tif
b31a9b4b5a6f535bc864bd6d72431584
6bc661821f66a8bafcd71e2e8196f89aa0c0907a
F20110109_AACSAQ gopalakrishnan_j_Page_012.tif
1e104cd20df21e54813ba3b755c4611a
603964b06fd10921f151c27a286249febd863de4
636708 F20110109_AACRVK gopalakrishnan_j_Page_037.jp2
5d88f8b7197049ca569f7bfd9f9b287d
2b29ea26ecf4abc08f20425db8283341ebee6eed
7507 F20110109_AACRUV gopalakrishnan_j_Page_018thm.jpg
b0be593d7d03322df8f53b814c1981f2
be029bda6c61655f4d076e283a7364ef3744c5ca
117796 F20110109_AACSBE gopalakrishnan_j_Page_006.pro
d77d86f55fd4578e03188911523acc88
b66ecad458dc5b121c12c4acf264f3024e23b77b
44117 F20110109_AACSAR gopalakrishnan_j_Page_049.pro
ac793d1e8045b38c4c342fb1b63c54de
38fb294f4c96c533b915363174f2aeb53528abac
F20110109_AACRVL gopalakrishnan_j_Page_063.tif
2e330e8ab23abc0beb83b483eba51709
eece28025fd360b8719f90c503cdb4875c7e6815
32915 F20110109_AACRUW gopalakrishnan_j_Page_070.QC.jpg
6b34287de34b24844411b038ebcf5487
d3c7719b137430bcd22e8f26c252038ceabfd03f
1919 F20110109_AACSBF gopalakrishnan_j_Page_076.txt
10d3a910d5c0621312d3e08209e4f2c3
2bfeb70ee3df09e87ca076ef762b9987f6d7ae38
13241 F20110109_AACRWA gopalakrishnan_j_Page_050.jp2
1c7fa65387e1cc011c8bb5fa00b76c02
4b3d3a6f8315130d0d43e8d976610fe33518e990
F20110109_AACSAS gopalakrishnan_j_Page_106.tif
01c1aa086950e49f25e0e3ce27af2644
455830dad890b08feb3d5be8f5ceca5453ed76a7
83892 F20110109_AACRVM gopalakrishnan_j_Page_099.jpg
44426460eb8f6ecb4eba5f9901733c36
ab2f7789d333bd6f48db5507ce7473c55ee207a4
85961 F20110109_AACRUX gopalakrishnan_j_Page_099.jp2
66da49c1e542e19203f1f54ffef346f6
5462136f55fc238491b041bd5eeabe818eae67ea
37416 F20110109_AACSBG gopalakrishnan_j_Page_038.jpg
e29738f2433c4a8a20b2f9906d6a89a4
ff88a08556a934e46aba5f47017fcac9bf3e33d1
826288 F20110109_AACRWB gopalakrishnan_j_Page_104.jp2
3c2a3abc27e880b4fadb9948c5424f28
ef5fdb27616a295fdc68c89f839f6007a16654e6
43214 F20110109_AACSAT gopalakrishnan_j_Page_051.pro
ef9592925a6e8bdfefd57d34294d33f8
952120a25a550c3c29aeb59861342419f846d5b2
2575 F20110109_AACRVN gopalakrishnan_j_Page_117.txt
d33d4b9f6d8dfb895be492b49fe6a4df
072beb5475a00fb1d1c57d0109af3e45f389a856
92978 F20110109_AACRUY gopalakrishnan_j_Page_035.jp2
92dc1d50834e623d7ba4e7c07448d0fe
6a7e50317ef06e10b6aff849c5bac3e26a830846
28963 F20110109_AACSBH gopalakrishnan_j_Page_073.QC.jpg
b163da8c1fb3e50896013824b9827608
5bdc17b885609a0eb6b350c7b88c44ad973fd5e9
53234 F20110109_AACRWC gopalakrishnan_j_Page_105.jpg
4db4e05d2ccb2b469eba0a1e1452909d
65696349086c89fe85259ab5188c66b955f14c1b
78273 F20110109_AACSAU gopalakrishnan_j_Page_028.jpg
b6bc7154c74f8117dd1430f3dc519e01
ddb57415dec88b133b5f4aead4df30c25eb41af5
93131 F20110109_AACRVO gopalakrishnan_j_Page_084.jpg
5bb463b9fbee9338a23be258023c8920
1cee020da32a7119ede80792450a153941202b58
26309 F20110109_AACRUZ gopalakrishnan_j_Page_004.pro
f6b51794b597115d68ee18781f6d9ee6
8cb74bf9cc66a4ac21e8adfb4dc7e96f973429ab
37419 F20110109_AACSBI gopalakrishnan_j_Page_063.QC.jpg
b09189161924d58531c8cf3d4a60dec3
92c6b68d1c34102d6698183bf2084818688af783
53893 F20110109_AACRWD gopalakrishnan_j_Page_090.pro
5c168bbcda1413e67ed719c90800c4b6
5d0863b969a4122b3a2d573d1374460c2a2bd12b
F20110109_AACSAV gopalakrishnan_j_Page_084.tif
82e7b070f92967fae21a4d9b82b543a9
865abcc521d97c798fa47cc61a545a10ff651422
F20110109_AACRVP gopalakrishnan_j_Page_103.tif
f51589f31f10f1481778e9f71c536a0f
18f6c5b1c4a220a3d44192f3a91fbbe26ca02b0f
25118 F20110109_AACSBJ gopalakrishnan_j_Page_112.QC.jpg
27db04614dd4966c209cb6438bc97353
6916925522265d4d3c953eb5b876d4eba04d26cf
F20110109_AACRWE gopalakrishnan_j_Page_007.tif
0bc1807b54aeddcf1962b3d670c18765
9b7cc288b80585bff5381c02e6606c2c4c37b19a
7233 F20110109_AACSAW gopalakrishnan_j_Page_032thm.jpg
a7fb8ee3f7eb470cb60b80779a13a3c3
31f81e8eb042f3cdc8d415e0ed55ed7bd830792c
F20110109_AACRVQ gopalakrishnan_j_Page_014.tif
bf02f3ded40ae96a2ff90d31212109b2
c19766c2c95c83f456d1d5cd14501ff04e15dc86
F20110109_AACSBK gopalakrishnan_j_Page_011.tif
ecc4041b1e41198ec12db3f4cd18688f
cc76bd46073c3b2ebd2ef6a3f59ca8d9e16b2e72
33244 F20110109_AACRWF gopalakrishnan_j_Page_019.QC.jpg
34ba883fad7cdf6fa01ceaeaf66293a5
ae573ced065050badae4c2947dd92589d34654d4
88673 F20110109_AACSAX gopalakrishnan_j_Page_092.jpg
07e0bed067bfc719b6de73181825afa9
c2237608789af75499160251c37992569f7d570f
31701 F20110109_AACRVR gopalakrishnan_j_Page_053.pro
eefa9996590e4843c969559d03c2ffb8
2459c5ab7af24fcf34fae81ce446ad3fb78a9c88
706 F20110109_AACSCA gopalakrishnan_j_Page_009.txt
eead95393c9c384f08f24dc6f1d5dc52
29e0bbf8cb240d1025eebde2b5cdf58bd20cc153
1156 F20110109_AACSBL gopalakrishnan_j_Page_028.txt
790f12fbdd7897df245e73d7bf0ad261
27e11d16ae1a344ea247ec36f8f224fcfcf04f37
141375 F20110109_AACRWG gopalakrishnan_j_Page_064.jp2
7c2566b8050a018d90427132f11315ce
3ea16f77481fb29fa7c40eca970a8493085a74b5
25460 F20110109_AACSAY gopalakrishnan_j_Page_113.QC.jpg
231a6a2f854e326dc93a1470d7cd0c31
c89d1cbad68bc0d67d1c3c17a0aef23be5a11043
51558 F20110109_AACRVS gopalakrishnan_j_Page_040.pro
943c7de646c10f7800bc230bb0fd3b33
fa8b7873d0cc118991a903449158bbfb865c47e5
30750 F20110109_AACSBM gopalakrishnan_j_Page_014.QC.jpg
9b249a5c058bfb858f2d60fb63e2d2c2
dd62dce62464fdff9db2172d793361ff050d2197
28674 F20110109_AACRWH gopalakrishnan_j_Page_067.QC.jpg
67e44637e1a4513ce859bbf0987fb010
6dd81ae71d011e07588295ab5c16aea0f2c3ba6b
102845 F20110109_AACSAZ gopalakrishnan_j_Page_024.jpg
ae56be5e6971eae26ecfa9932198a7d8
fb7e1cf0493cdf5dd0534330b82e839638b8c55b
27461 F20110109_AACRVT gopalakrishnan_j_Page_093.QC.jpg
ecececd38695e2d1e5285bf4754b331b
2f03821230828b4191dfc692946c2d939f530c41
864 F20110109_AACSCB gopalakrishnan_j_Page_119.txt
b535f6039090aac3907391eb699923cc
e968f710dc084133d8a59ca2bf613e7d2d591c01
99735 F20110109_AACSBN gopalakrishnan_j_Page_088.jpg
270522b1129c00b9ee44ea20903cc199
c6b119ad88810f9893ba8dbf47c374ccef9d4d63
50658 F20110109_AACRWI gopalakrishnan_j_Page_069.pro
45807fe3f84954d7c46038c94b8abe47
1d16e4a162ba125fff0b28c08025842656181f52
1787 F20110109_AACRVU gopalakrishnan_j_Page_051.txt
64b3dc766c11b15726d10ef2bd0ee0dc
8ce2c1799eed10616b3e6620a706670d78491edf
49495 F20110109_AACSCC gopalakrishnan_j_Page_113.pro
59a4178d7a81ffcce98f87fdb1e83186
1a2adec1264a3486f0b5e74b9b1d6e8906c0b14c
973369 F20110109_AACSBO gopalakrishnan_j_Page_096.jp2
c96061dda49927ea673af2def5f50510
b19e19258a01dfa80f9c574407c1ef43a8c42ba5
45782 F20110109_AACRWJ gopalakrishnan_j_Page_097.pro
0b1b881c1a9874a5217a993d696b8e97
4ce16c46c04c91a16ad55ff5c57319fa95daf881
1674 F20110109_AACSCD gopalakrishnan_j_Page_110.txt
6baea13d9d28a9be6b90f95cc4c6624a
aac73ab5a8b87fc47dff8a59e27eb28026529efe
93707 F20110109_AACSBP gopalakrishnan_j_Page_065.jp2
703cfcebe58cf9d729ba4885873e2adf
be493491b1ddb5fae946c85aaa202309da953703
7300 F20110109_AACRWK gopalakrishnan_j_Page_013thm.jpg
613fcd27b6d738d505f6243147d7028b
9467439dc3b0188bad47721386bb78b294251e03
97552 F20110109_AACRVV gopalakrishnan_j_Page_060.jp2
0cad42af67b7583a5b13f3a5e0b5c957
5a2f1af9014b0e0de5e15693bed496daa2861166
90368 F20110109_AACSCE gopalakrishnan_j_Page_074.jp2
028673d3605a4619596dce49228a54d2
e7da375548dc1bb407ed18693bbfa59479f9e7c4
F20110109_AACSBQ gopalakrishnan_j_Page_085.txt
1cb1e89081c66be0ef1313a62812facf
f581f72d20a97813149b42f6f0c9296df7526ebe
1034 F20110109_AACRWL gopalakrishnan_j_Page_062.txt
caacdf3b17f520ea3f1b62b77ea9df37
cbefe7cd4158b345bf6c72af1ff78a9ab1769046
39555 F20110109_AACRVW gopalakrishnan_j_Page_099.pro
9120382dc8ac23f980dc31c93fe693be
64a4da86cfaa632395b03d844aaafc51389e1071
84855 F20110109_AACSCF gopalakrishnan_j_Page_083.jpg
faf91b21a7f755f42807dfe1579b781f
183be52a433b82e764454998b449070fc47ee494
1928 F20110109_AACSBR gopalakrishnan_j_Page_014.txt
114dcdf96099e0a9514aec51d7422151
ef61c17c563e119ae7c25a163db6ba13ff3f6183
26529 F20110109_AACRWM gopalakrishnan_j_Page_032.QC.jpg
4a77f03066f0ac6c2df622e6c904dec2
3fd0620bb1a9604d825e52204b7aaf48f3ae4f14
1829 F20110109_AACRVX gopalakrishnan_j_Page_100.txt
8f926bd7065ad9e8cdc6ee1ad4de3ef9
5d7a49706d82d33b2f0d8fb7147031381a59141a
786047 F20110109_AACSCG gopalakrishnan_j_Page_029.jp2
f60d57ab2626d71f3fdd1d4f1a9f3179
b17347de0b47bc9fce0641ff522c5a8233d1fafc
2265 F20110109_AACRXA gopalakrishnan_j_Page_083.txt
698a6a18adeafcb037a527f909b90c44
3f1fdc27cbf35c6176e4d2b4f26db697619ab374
89436 F20110109_AACSBS gopalakrishnan_j_Page_093.jpg
bf3eba690306663932835734ac33feea
2187e6a981dd10b5a92d202c7c3cf6402516578c
845109 F20110109_AACRWN gopalakrishnan_j_Page_020.jp2
10675f88b383ffb67316b5fd8bb29f55
0c1c91e7491d26eac63f8c65a1b9c14f700804d9
15198 F20110109_AACRVY gopalakrishnan_j_Page_119.QC.jpg
39fb7560d79725ed107f0f82c7e30aed
ad89c7814aeef5a6a0e5ab741133969cdb34bed0
F20110109_AACSCH gopalakrishnan_j_Page_059.tif
1ba44c2d0e74c622ce4c1f817255b0a6
3853ae48e41c78f5680452357a027579ce0d51ec
F20110109_AACRXB gopalakrishnan_j_Page_040.tif
7de29e01b1b008bf28af3a6447f97477
10a8e247ae3f0c44918c91337ff5855cb514f7d8
7765 F20110109_AACSBT gopalakrishnan_j_Page_081thm.jpg
136b50e277ede71e6335e34bef9da417
5b82839b0744e2aae147c84dc220cdf4d444e7f7
7044 F20110109_AACRWO gopalakrishnan_j_Page_053thm.jpg
4434857c96c06be5724397f65c664a78
7f8c9dfb5594b766f95f8af824f1ab90980de83a
24135 F20110109_AACRVZ gopalakrishnan_j_Page_030.QC.jpg
a412cea967e038f5b7bd577f2f9326b4
8126df35dd26381726dc610a46fb0e3483dee467
F20110109_AACSCI gopalakrishnan_j_Page_023.tif
92a7325069834759af007c81030e794f
b182882796678b4821e668d72e5a009cfa27af48
39249 F20110109_AACRXC gopalakrishnan_j_Page_031.pro
c46ba6f83ad7d1c9dddc4e52bdf0bff0
8c4ea6254d2cd694b86e79c767387b22cbe37d0e
41606 F20110109_AACSBU gopalakrishnan_j_Page_104.pro
e571351b2298e2e94599fba35f669349
3b3ab829f356707f87f8d0b736dbe30f85ac692f
F20110109_AACRWP gopalakrishnan_j_Page_039.tif
a004618ff6d65bb2712232e58a8ad8f0
f9b5316892137866ba5ebe6dbe32ce7bf722d4ba
6588 F20110109_AACSCJ gopalakrishnan_j_Page_094thm.jpg
9bf49b5b7490acb1d0e0fa82accd13cd
d39a96d2831ba7f9b630f42ca87298946a202c27
28242 F20110109_AACRXD gopalakrishnan_j_Page_092.QC.jpg
d8e4a70871bd23bbfecff2fddf6b33bd
54195ad71c4c90a595a1d6c85d2aa253b70bef7e
26909 F20110109_AACSBV gopalakrishnan_j_Page_095.QC.jpg
ffb77ba84a043741b7f057fbaafb96c9
ede8ab8423b7ff7f99eb1465d7929b1466d338fb
25941 F20110109_AACRWQ gopalakrishnan_j_Page_055.QC.jpg
825da5e98db8e02d5f35962f29468ae6
2ae696bbe1b4a689653c135b572b8ec6d5cb27a5
7357 F20110109_AACSCK gopalakrishnan_j_Page_062thm.jpg
db000649d3d775f5b73b59492678c9b9
8e9655fb96e564e14f6baa6bc38a816b3a09cc11
29727 F20110109_AACRXE gopalakrishnan_j_Page_065.QC.jpg
2fbd5b6c313d16758a76930f7ad7b4fd
c9a723f144f0f9893416cbc2e539f21f1fac4e80
F20110109_AACSBW gopalakrishnan_j_Page_085.tif
808f9dd4f1be47c8b08f29d9dc0140e7
2425426e33cfa5304c8f1104b48f114943c685c4
124084 F20110109_AACRWR gopalakrishnan_j_Page_080.jpg
cfd07a3ca137fed7c1a5cee5e170bf1c
9f44e0f29b2fd855982aea8a1cbc9c1ea6080d85
F20110109_AACSDA gopalakrishnan_j_Page_072.tif
8196926a037125f26bf71d63c5be7a66
b61537a1c2e41d8f663f3b49c6134f906c1c3715
F20110109_AACSCL gopalakrishnan_j_Page_038.tif
45f3f551fc2b3ff9f1ec516837b61e4b
c5c3615a5022ed9de7582164a576d76ca8747fd3
F20110109_AACRXF gopalakrishnan_j_Page_112.tif
c1f401422019c5d40a4f8b1044ccfcc4
18e6ec242d3cd07bac1a7d8c9164621009860396
1693 F20110109_AACSBX gopalakrishnan_j_Page_106.txt
43d4036a46c7d10d05291399ee839835
41983a1fdd0e83a301a1ea421c18ab41056c55c1
26052 F20110109_AACRWS gopalakrishnan_j_Page_010.QC.jpg
06f37fb88176b93e8cab9ddd8dbb9fc9
f4d05ca50a7051fc7740e7296ae509b52c5adce4
44949 F20110109_AACSDB gopalakrishnan_j_Page_018.pro
513fef8102861af1451008ce01182457
b5d9812d91aa3e24bb1f36e079b2e8324b1d3710
F20110109_AACSCM gopalakrishnan_j_Page_094.tif
a0e378aa91ade76c25aea0805d6ff17c
1f7bd9e01dffc144e1eb375c7786cbcc4178a728
69815 F20110109_AACRXG gopalakrishnan_j_Page_110.jpg
bab6ab7768e9759068df605be59fed0b
80818f2ce541f737e7ce41ecfa6167b53b610bbc
95579 F20110109_AACSBY gopalakrishnan_j_Page_073.jp2
835ed411cbc6305ab9b0730ddf50c8e9
09dc780c35efe83eb33f18dfc804c1afbe58affc
24174 F20110109_AACRWT gopalakrishnan_j_Page_082.QC.jpg
53cd6583fa39379f3608fd44686aafd3
d23ca974cde56ca6f6b3e922f74ad0a92e8532cd
8294 F20110109_AACSCN gopalakrishnan_j_Page_097thm.jpg
a083bc950c9db9bd16da7d0c52d435a0
4af5b00254975dca3f17e9084cdc4cb8ef1cd28a
6820 F20110109_AACRXH gopalakrishnan_j_Page_052thm.jpg
01cf95765c7da88f36b4627833f2d18d
c166e9ea5c8ac705c8f4c605a648548ba030096e
F20110109_AACSBZ gopalakrishnan_j_Page_113.tif
ca3bde0aeee5d7ef030a8c1d0dbe4986
d898e6493cc8623dd6f4992bb60f10ca890aa1cb
8873 F20110109_AACRWU gopalakrishnan_j_Page_038.pro
8c671bac4efa3bc883002befadc50636
23a1c2abf44a56f96dff49ce7ae666d1d6952b3d
958 F20110109_AACSDC gopalakrishnan_j_Page_043thm.jpg
b5d1ecd224559d61bcf3604edac2f802
e222015a437808fa97d139f918154b71bc4e5d9f
103246 F20110109_AACSCO gopalakrishnan_j_Page_069.jpg
4dd63aef2cd7fdf8e45d2df0787ab118
1f41328c75c3f6a1350fa80abcb6005fca28e77d
2362 F20110109_AACRXI gopalakrishnan_j_Page_113.txt
273cccafa8fe32b36527768f0d9b9549
9cffbed6d52336633ac6614c5e43f584e9b859db
26873 F20110109_AACRWV gopalakrishnan_j_Page_076.QC.jpg
6018eee584eb15700fdfb9cb0546aac8
c541b98e07adf98196de178157d523413e945d66
F20110109_AACSDD gopalakrishnan_j_Page_080.tif
f807189a449acc4291210b95cee1808b
8c6b96f5bcb2fccb469f5667d3e2bd87747f9b0b
122952 F20110109_AACSCP gopalakrishnan_j_Page_026.jp2
bc488cf56f8de8e79ed7c209dca1fb1d
e3a31b96ad99673560064a06c3cd59b8bd4acb16
22464 F20110109_AACRXJ gopalakrishnan_j_Page_108.QC.jpg
d9110a86b185f022b431f52eceb8f426
0fc391b471cc9cf3657d15e5d4cbea8fc91cb41a
87 F20110109_AACSDE gopalakrishnan_j_Page_003.txt
310043383683ce3b42d657c431db5b67
3d85e03cb1f0359a8b84789e5e80140a0d5661bb
2755 F20110109_AACSCQ gopalakrishnan_j_Page_081.txt
24b38738ea312c30ff9d6f5c5081e272
fbd688f06cf2b50e1cf590569ee01ae0b295436a
7980 F20110109_AACRXK gopalakrishnan_j_Page_088thm.jpg
aebf7e6ab4258a85aaa7e722ffa163d5
f1afe1c561ddad1e53f2ddbce7ea2609b86973ea
32105 F20110109_AACRWW gopalakrishnan_j_Page_085.QC.jpg
1577104ad25f4fa42fad3d799178856d
7d60df677f5422525b72d1b2922476d32d3e0aed
1964 F20110109_AACSDF gopalakrishnan_j_Page_019.txt
433e8496dd855a8650196052404a37e0
6f61dfbe6f59e13db0fe4e1b7417c6bd8468aebf
8236 F20110109_AACSCR gopalakrishnan_j_Page_090thm.jpg
cf69a8fed46e2582d9bc5f9b72860164
03d16bd89a37d8b634650bf7a8da60aad6b88797
117377 F20110109_AACRXL gopalakrishnan_j_Page_048.jp2
4ce9b5e21c10a8bcf64c7d22fcd9646e
d64e7aecbb3fb5bd9e4377378aa8c9c7d3fb3621
26274 F20110109_AACRWX gopalakrishnan_j_Page_016.QC.jpg
4a1c20fc0051223f9b14911e095be155
7bf9a6e2ccb3897cff5af42aca57220d2dfd3f9f
F20110109_AACSDG gopalakrishnan_j_Page_069.tif
1005ef10b4c2f9ea8e2ed4ee3e242ebe
796097f97d8ae4e957281e4abd4897c47c767fe6
81525 F20110109_AACRYA gopalakrishnan_j_Page_017.jp2
3969bb5a46bfe3117dbe1d4be9b2eec5
ca19231f46f65a50c0ad1252156bac920ecdaf48
102575 F20110109_AACSCS gopalakrishnan_j_Page_040.jpg
5dcb0bef861eb90b0e6e8d2fff5859ff
577a8e4e212d34e58b937254e9abc1b2f29f8308
2028 F20110109_AACRXM gopalakrishnan_j_Page_118.txt
d514f0405df56128956caac1f9f52a12
bb526c92e6d840b3333470a53303d0c4386f1cf0
98164 F20110109_AACRWY gopalakrishnan_j_Page_068.jp2
03a01c83d0559b431c6143cae2b2ad67
700cb43c7c2e02925fcc30a9a09270d9360c93c1
F20110109_AACSDH gopalakrishnan_j_Page_068.pro
802db21dde72e546ffd0fc2bad4a0b25
c25c01849a557f6a79565f39e227dfafe09a64ec
100985 F20110109_AACRYB gopalakrishnan_j_Page_088.jp2
4b05d589694246299432042eb945f35a
731b046ebf304c8a7899a3dfa482076625b80f5f
2679 F20110109_AACSCT gopalakrishnan_j_Page_075thm.jpg
92c6ec42f445805d5c9611821fd5aab8
5ab58c8e310dcd115118202cb8e07c32a62e784a
22337 F20110109_AACRXN gopalakrishnan_j_Page_029.QC.jpg
0a3e696e7c2ad8a1e961398879248ccd
44b7ebdc9bc2ff489f5207087bbaaaf19991ad13
1808 F20110109_AACRWZ gopalakrishnan_j_Page_046.txt
59a66793055078366e335a55b5c0ea38
f91a3631dd3575a67d1c86abd770948028601677
7945 F20110109_AACSDI gopalakrishnan_j_Page_066thm.jpg
7e5696240a988cb82f2c38cca44381c7
05cff1c4110d2a5e99ea917124d735081945f0e3
2096 F20110109_AACRYC gopalakrishnan_j_Page_040.txt
294a3d1f2cd593602283a20eaac2bf7e
4426ab35e8dd34b2b6e239f606a962e48b93900d
22335 F20110109_AACSCU gopalakrishnan_j_Page_106.QC.jpg
463bf50b4b44bf6b5dfe863ce3d3564d
1adbac88af7ae9825dc43f23377f660d7e73d7fb
7544 F20110109_AACRXO gopalakrishnan_j_Page_077thm.jpg
b4a0d32567ad8fb40416903c2ec16ce3
a934a36d055cbaadd6d375a01e068a554e1851c3
91214 F20110109_AACSDJ gopalakrishnan_j_Page_015.jpg
6292f695f50bb44c90ff741e3cbff08b
45f143548c6bd366f5c2d0b98aa916ec348a9a2d
F20110109_AACRYD gopalakrishnan_j_Page_008.tif
1fd98d07bd5ea5bdb12026b7476a8ea2
e4766ffe49da5b0daa2f62053d5348b51ee05ce5
F20110109_AACSCV gopalakrishnan_j_Page_029.tif
f6bb07b4bd8557fadc76442d2913a535
50e396f5920f831f1932f40badef553e58015ebe
242 F20110109_AACRXP gopalakrishnan_j_Page_098.txt
72d563fb683c56b8261cfb677730ac33
487dab9a36008364d107c44530eb240bb1d7e83f
30759 F20110109_AACSDK gopalakrishnan_j_Page_018.QC.jpg
23a5646fb9b90ee5871ba96a3b529657
bae94d244b9000b1a7b997d785c6d32719eb4c62
27801 F20110109_AACRYE gopalakrishnan_j_Page_034.pro
f6e87a05b71534585ebe54bdf9aaa215
812b83faa8a81921de595fd420a2ef8afab3d2c1
7149 F20110109_AACSCW gopalakrishnan_j_Page_079thm.jpg
d38fb5353e86e1e42caba40da070ec7e
8fabf0ef74090aa7e6e2b4f68cb5bf765b18d0ea
603 F20110109_AACRXQ gopalakrishnan_j_Page_115.txt
34ef900b3610218db4256860b8ebcebe
d3d45c3c9655c4f7417467f9e893e25a32b18c95
1780 F20110109_AACSDL gopalakrishnan_j_Page_058.txt
7269ddc50d64fdfeb97db7bf700422d5
bb1a6f2da4837f59b7620ac1ba5bb3507d06b40d
1614 F20110109_AACRYF gopalakrishnan_j_Page_094.txt
ac36d845206bc2abbcc169e196b2a906
fd4bdf256dd84e609a8c537e27a7626c170990e9
1938 F20110109_AACSCX gopalakrishnan_j_Page_056.txt
2df5f3633dd2250b614d6875c46d47ff
036ee813fff7687d74ff882b1799a872c6dadcea
7656 F20110109_AACRXR gopalakrishnan_j_Page_042thm.jpg
224f8d049896fded8f2e9a80c351c433
4bdfc7cda98c31f3eab8871c1a7e1ef20246cad8
4779 F20110109_AACSEA gopalakrishnan_j_Page_098.pro
750d7e397eeed2488b5caf703218e9b2
aa4bd1f6f26163f041d346175f7d19d2c6d36cc5
79045 F20110109_AACSDM gopalakrishnan_j_Page_017.jpg
69572185e87b3630fd96eedd7ee724bb
0c6887fe6ee2f5196af658a1642eb909de19add9
8303 F20110109_AACRYG gopalakrishnan_j_Page_070thm.jpg
fd00d759ce2e040dd86cfe31f534f905
0d0d421a0ca48ec96c73fdc04827422bddd62e51
85489 F20110109_AACSCY gopalakrishnan_j_Page_032.jpg
13ca4a96072114d70843af58eedb5188
d73335e232f2df6df00ea3912eb8d2ccc418d8a9
29506 F20110109_AACRXS gopalakrishnan_j_Page_040.QC.jpg
e034af4920d5e5aaae71d6794520fced
40669f01a8b5055a49943e896cbde2d8ca943041
456 F20110109_AACSEB gopalakrishnan_j_Page_038.txt
f75ddd21a63f3359042776eb56693cb0
0731320b2c27cb54838be0d606242ad1fdca6fcc
109394 F20110109_AACSDN gopalakrishnan_j_Page_069.jp2
2a97051f473c467dc2650bc7e3e3d83b
c95edc12cb464b280d17c83488c59aa8c8f8720b
88781 F20110109_AACRYH gopalakrishnan_j_Page_010.jpg
7707ae196a490a9f88b02624790b79f5
c3d0df0bc022e1cd0820f038e5a4c465465a8b3e
79059 F20110109_AACSCZ gopalakrishnan_j_Page_059.jpg
c105259ce59090ee64e00eae741862f0
d7646ce1e97d2b65c57a20c252f1319a938aa492
7518 F20110109_AACRXT gopalakrishnan_j_Page_065thm.jpg
2f4217a933e2c423f3841e19645975be
9a43263c64a177b50b38970d651657134497eef7
7621 F20110109_AACSEC gopalakrishnan_j_Page_072thm.jpg
bcf319c97ab925487aa41d3f5c5dc3d6
8ae4a8ffca479ca86d626ed2c0ab3c1b9c831abc
2009 F20110109_AACSDO gopalakrishnan_j_Page_072.txt
08162ddce1522e5d5bcc12316ebba01a
893dddb69de237129e7a8d057db62cac5bbf38ca
22377 F20110109_AACRYI gopalakrishnan_j_Page_057.QC.jpg
d432b0d913359f8045d35d739f87ad56
0a5eb2601195ee914a589937ae523ff8c8717c9b
88890 F20110109_AACRXU gopalakrishnan_j_Page_052.jp2
3cef819540a1741db5e9ce0831388ed5
c93791b6f83a6efdbf3ee29ac9d3f75cad4f85c2
6424 F20110109_AACSDP gopalakrishnan_j_Page_010thm.jpg
8e158651eae2607ac2ff8824ce3e2978
dd954734fd935b2d4f1123da16077f828ed69a8b
7144 F20110109_AACRYJ gopalakrishnan_j_Page_116thm.jpg
7fb4f56837243610ecbd1c17cd64cf33
7f939dde7e207bec0f577ca1d0d8c3e3ca453303
7257 F20110109_AACRXV gopalakrishnan_j_Page_059thm.jpg
b9160b09346e3a510e5b51591d39d267
818b7c3784b2c19b87402e871da4f1f56cb37b1d
1051976 F20110109_AACSED gopalakrishnan_j_Page_007.jp2
b09ca7ca4a714d63eb3f90a8b721bf31
4903794b12329cdec74ac75b35b7f1a69080d170
90710 F20110109_AACSDQ gopalakrishnan_j_Page_096.jpg
46ad645774c77a0e19a389cad4f9a2d9
9c9c5c005eba5967f4396cbf9f0c66cff6d2982b
29486 F20110109_AACRYK gopalakrishnan_j_Page_084.QC.jpg
dcdf91d72d557d57542341c32f01252f
b2e02fd9e10b3b9f54d87787ce98f1860bb514be
6720 F20110109_AACRXW gopalakrishnan_j_Page_017thm.jpg
18c12e3028a36f05e8419a8897d3737f
2b1f188a4e196c33e6329ceb22f82f64a6f9e144
1863 F20110109_AACSEE gopalakrishnan_j_Page_088.txt
50a1e3c583b2dee90bcfb106f6e3f6f7
1999a39ee9066f436ca41a02cd63a4d177304dd7
3054 F20110109_AACSDR gopalakrishnan_j_Page_009thm.jpg
8e45765431a560c0b91a9ba404bd6c7e
4c0b0ecfca1dd4b3fbdbefbc1b722d83eda78d08
7379 F20110109_AACRYL gopalakrishnan_j_Page_054thm.jpg
171bf5452cb67ecc5c24006f49d3b1b9
d542bff15e5d7f3af88ff89f01b8dbbf7bee2547
F20110109_AACSEF gopalakrishnan_j_Page_096.tif
8dbab6d1df14ba497da139df5f1a867b
8e774806e3df90428b3044a3c9d41397268daadd
101830 F20110109_AACRZA gopalakrishnan_j_Page_100.jp2
dc6cf35068fcb3ac7fc482710cccc51a
91eca013f286412e9eb18003d81d7e346fc87812
7748 F20110109_AACSDS gopalakrishnan_j_Page_014thm.jpg
3be8cd78272a25afd4e48a7aef0dbbeb
65a66f66cd63d6eb8fa3483f1377907ad1764ea5
7798 F20110109_AACRYM gopalakrishnan_j_Page_001.pro
4d9c0c3c0558f094cfd29b11ff785b93
525159d32c84ce77edc5c8c65faafc6527c239ea
29178 F20110109_AACRXX gopalakrishnan_j_Page_036.jpg
04f8c04d95c455855cc0f8c99e2fbffd
d4096863e1187e5c54d7c0fef9ccefcc6ae44b40
54552 F20110109_AACSEG gopalakrishnan_j_Page_008.jpg
f9f374daa7f5a3f62da131eb0a5e3abf
de5e7312055c4b0f520400c8cf9d32bd0c142e20
1912 F20110109_AACSDT gopalakrishnan_j_Page_002.QC.jpg
c19c8defe75d85965f52e396494ddeeb
06cffe7d1e64b85c34f1521553d7953ef59ff39b
85071 F20110109_AACRYN gopalakrishnan_j_Page_031.jp2
594359a80c42bf6b0dae0b1bca4dbeae
0b617f9f837e9bc4d6a014463d687f941c8a4aab
7039 F20110109_AACRXY gopalakrishnan_j_Page_076thm.jpg
499522e8f52deb1326dc35b1a9e93629
30a043675dab190398b3864de066a62e06238aa1
96065 F20110109_AACSEH gopalakrishnan_j_Page_013.jp2
e93e3c474571ef48e5150ada1d6a6980
c7af2ab98d0ac9315bfbb9592eb12f3c01911356
93109 F20110109_AACRZB gopalakrishnan_j_Page_073.jpg
a35bf4afcd041a7d2bbde8715af8bfab
1a471560983faa5601b34a1fc07b00cb456454ad
F20110109_AACSDU gopalakrishnan_j_Page_097.tif
48a00ec3b552ada3efe28cb98bf70972
18c30b5cdd5a94e1d43346259430b48225a515c0
96990 F20110109_AACRYO gopalakrishnan_j_Page_018.jp2
85b0f5fae1790c6f10ed5517004bc231
b5273791320ea15c09e87319398bca389cb8971e
103449 F20110109_AACRXZ gopalakrishnan_j_Page_072.jp2
5ce661d3499943fec6530ab9636ace19
efd9ddd509fdc3abeba40a94eb6425227157b800
693 F20110109_AACSEI gopalakrishnan_j_Page_002thm.jpg
5f6430d9c5e9dd414b50c95bb8a0b923
6f5584cd72d03e43980fac7462285552b76c2ebf
F20110109_AACRZC gopalakrishnan_j_Page_003.jp2
8abd9d156fceeba336e51d8ba4d4143c
e25c611cfc22459b158f0b87eaa08d3043c97851
F20110109_AACSDV gopalakrishnan_j_Page_105.tif
3bc14315b305a0cf42719911d9b6f29c
6be2d18bc9cb79ac20c718e21350743700077862
F20110109_AACRYP gopalakrishnan_j_Page_042.tif
d28711bfc989ac462d753eb3247baaa7
f2b99c3c3221b3f43d56586d9065521fdbf56c38
37145 F20110109_AACSEJ gopalakrishnan_j_Page_008.pro
c6203d972d73a9c2cd12141bba58a2a6
543f5534272d0a7d123eb8e0bc8e0c1727ad4bd3
F20110109_AACRZD gopalakrishnan_j_Page_061.tif
aae4e2b5cd20383fb8a6754f0f1b5746
2946187cc933669cf602d90d224999a9e767efa8
1056 F20110109_AACSDW gopalakrishnan_j_Page_003.QC.jpg
8c8d7133c7e5bc7250c36a5cb113ab65
a278c537a115d65a7266ce487a182aadea08492c
64890 F20110109_AACRYQ gopalakrishnan_j_Page_111.jp2
1b191c68e8d3f6d680fa6ec8c95f379b
a0f3ae5df3e79e927cd95108e8769775116b6fd3
93676 F20110109_AACSEK gopalakrishnan_j_Page_046.jpg
09bf0d39b0c78d7cfa36f6a43d926563
e527f8365e636e241638b110bc926bedf3923c60
1051966 F20110109_AACRZE gopalakrishnan_j_Page_005.jp2
70ae0d0e149a8e09f9b8f7cc9f453269
1b5c8d9480cb61e1f74da4c8757d387cd625f24e
27005 F20110109_AACSDX gopalakrishnan_j_Page_031.QC.jpg
54c760662c16f3137c07373ffe9f4f57
d83d89d82807c4e3b2c5b36e787ea8c8db1e3c36
92871 F20110109_AACRYR gopalakrishnan_j_Page_101.jpg
49a84c6e8234c84ec01cb99aa532df04
7dbfc1ba16aef5b91a3292c60aa47f20f6717565
42552 F20110109_AACSFA gopalakrishnan_j_Page_083.pro
c1fd87b8553cec82580849365331ef4f
72719faa5bf7fefc4996567e517ece5d76eaafd2
97442 F20110109_AACSEL gopalakrishnan_j_Page_046.jp2
ba49764549ee53c0ce4e13205cd23528
3ebb09c6942929d66ad77aeafc731fc5b9e1674f
7484 F20110109_AACRZF gopalakrishnan_j_Page_041thm.jpg
7b2db1325573a26fe3bdde2ac9723853
bb3c72eacbf1f983fb5a42b828d19b4aab8f8ca3
11090 F20110109_AACSDY gopalakrishnan_j_Page_037.QC.jpg
ba0cbe0887f792515af69c7d4063d971
f3ab33ac22f7ce3617ee143806965f8a0b28370b
28645 F20110109_AACRYS gopalakrishnan_j_Page_068.QC.jpg
0f44e82f13ea057a3ce1acd3f2c0ebf1
30237c0af20f8dfe0cac7c78b0633ababa7c8ace
62775 F20110109_AACSFB gopalakrishnan_j_Page_012.jp2
6781dde8d80d52fa569b299cf07589d6
c816736d3ae94ccb01d9ceeb281f373c68431030
440 F20110109_AACSEM gopalakrishnan_j_Page_001.txt
8c9840d52c37c9937d7a12ff11217fb0
cba6b3abe9d40957e259377286d70ee67b7ae706
12734 F20110109_AACRZG gopalakrishnan_j_Page_050.jpg
e39c875ae4d07b6bd819bc84e40d29d4
4b496a5d797a13703dc930224981b8c7ee1b9762
106938 F20110109_AACSDZ gopalakrishnan_j_Page_040.jp2
05f07544556ae91c7f779ddb2ec726ed
9516221ecbc129e5b83fe64bf895b10d1a309f52
26805 F20110109_AACRYT gopalakrishnan_j_Page_079.QC.jpg
43682b6f91b95bc35cab36878dad6913
bead1c3652f0f666df4cc28fc42c94c763244c4f
1816 F20110109_AACSFC gopalakrishnan_j_Page_068.txt
cdae1ade03e23e640915d89884d30ee9
b8f706034e5e9fd6cbd628a0e275452fe13f0a51
F20110109_AACSEN gopalakrishnan_j_Page_115.tif
510495595403059f049dbe181601e095
a42be557347a07a3f0deee654168634e9ee20a7b
10618 F20110109_AACRZH gopalakrishnan_j_Page_075.QC.jpg
d5bc644d35167e40d0093d559ef69850
ac0bcd8db0da2546f2d840a326941ec794cbc929
F20110109_AACRYU gopalakrishnan_j_Page_051.tif
2584498f9b0ecd24083079623a29d7a1
51d07fa1f5aae9209e37682fcb415131e3f7a2fb
22144 F20110109_AACSFD gopalakrishnan_j_Page_109.QC.jpg
9d8a37aa759518444f66f933e4847082
acf27fe979b4cc9e5435e024aae0eb48b81cfb7e
1997 F20110109_AACSEO gopalakrishnan_j_Page_066.txt
77a7e3bddf9aafc7a2022b0a9ecaed77
83c0a6c38c2ec9b51271b59dc966eb097b17ef58
27016 F20110109_AACRZI gopalakrishnan_j_Page_103.QC.jpg
3349a2b309cc952d3198e4cd35fb7132
cd23d78f5b5fcb0cb08a6903a037e6f3832539a5
125730 F20110109_AACRYV gopalakrishnan_j_Page_021.jp2
8535397440d0062347a70d88efce51df
43339929fad2e243320822054ae9b21eb6f02127
F20110109_AACSEP gopalakrishnan_j_Page_092.tif
1f2e41e98503742ec18e5434abde0a0a
d848e39ec66d0dd1c07ac228eef26eb2eb7e72c9
21669 F20110109_AACRZJ gopalakrishnan_j_Page_034.QC.jpg
4f76e9b07ef170856512877f1db7e420
fb1d0834773897a60279375dd46386472a989c92
88388 F20110109_AACRYW gopalakrishnan_j_Page_054.jpg
bf7352a5bd6f85223cb28273ac014f21
c3f986ffc10ce6b2f38b7bd8aa60d51c44fe7f9d
F20110109_AACSFE gopalakrishnan_j_Page_077.tif
779f578d6bd54fc776c2852fb1e18d15
f58d0c3ca76124c01d9a785615d42d531b9f1a75
F20110109_AACSEQ gopalakrishnan_j_Page_055.tif
7326a24734f63b16fb08113c268aa6ae
8d49b970c0ae38b9b7b9ea74e1e46d7b84fd8a10
7802 F20110109_AACRZK gopalakrishnan_j_Page_102thm.jpg
698bc6b0d341cae7cabc23c44b5f60af
e65a55efe9c485d3848f3e9fb3804fad551b13a9
3178 F20110109_AACRYX gopalakrishnan_j_Page_043.pro
b6cb67409b9f4049d13ed1e2f5da077b
5720fefcf073b4fca66acfa6a9b069049174d07d
47299 F20110109_AACSFF gopalakrishnan_j_Page_112.pro
b45b5b4a4513f3e1b6558945eac74ac5
52da3bb2c21b454fe9fb9b9e6bc4562dddbe6b4e
135030 F20110109_AACSER gopalakrishnan_j_Page_027.jpg
cc61ecae9c6724230577434ab4157189
29cb11fdfd3834674391d55f2a39a0d4716b939c
31970 F20110109_AACRZL gopalakrishnan_j_Page_030.pro
b6f67f51316dfd051af0b546b4fd408e
b0e4d9d7b75afaab5b5838c83c5abf68f761969c
F20110109_AACSFG gopalakrishnan_j_Page_078.tif
85c57bab13d4010938b5dd7713f67fb4
36a74757b4982bd725de76960e8eed788a0f325b
142056 F20110109_AACSES gopalakrishnan_j_Page_027.jp2
ceee036e85da8b14618ae8a291f82905
34d987f2eee081a97f5144c125210172acae44ac
38961 F20110109_AACRZM gopalakrishnan_j_Page_114.pro
d815e3fae8a1cb1db0632b83744deb51
c7a6647a0838cbadc82bf9d5bc1db5569fb2ee0c
30275 F20110109_AACRYY gopalakrishnan_j_Page_046.QC.jpg
ae238acf0e34b884a18935f9e2c5bf1a
24e9451bb37abb362785da0d730aca97abaa5b54
98312 F20110109_AACSFH gopalakrishnan_j_Page_014.jpg
8411a643b9485c1a313a6e00a8e62fe9
7fbce593d8438136eabb691338e7d894dd92f999
33524 F20110109_AACSET gopalakrishnan_j_Page_021.QC.jpg
c979ab11f7e4269c89c35f15571ed8de
f527f0e343124a7b34a0173cca56a976ea9020f8
5502 F20110109_AACRZN gopalakrishnan_j_Page_108thm.jpg
1f8b1892b5ff350e2d451d981ea7bda3
edece9b84e3bc3dc5c0525b2c5e70baf8054ebdb
86113 F20110109_AACRYZ gopalakrishnan_j_Page_104.jpg
fd7dad1a46c847fcd6f32f5532f44c3d
0fef6042f4f74d1444f263a14e4eebda070d2a88
901155 F20110109_AACSFI gopalakrishnan_j_Page_095.jp2
c6b364ffee47f044f56c5b753dea61b9
4ef1d50d0d17b8e30e7711988823d8d11594ce1e
87003 F20110109_AACSEU gopalakrishnan_j_Page_033.jpg
657f9841479ba625ad791ff02800a697
3aeb18db517573a2bc3b6acc504a7c0a4fb999bd
F20110109_AACRZO gopalakrishnan_j_Page_058.tif
5afcb70fbcdd8ad0af45c324504e3144
6de7fadf646e8cb56b3a4f49bf4c83782ef41eac
1114 F20110109_AACSFJ gopalakrishnan_j_Page_047.txt
e2a199e1cf785711b1f631c8b542cf99
b78210b142cab6a5da868771c52702078240ef3e
5532 F20110109_AACSEV gopalakrishnan_j_Page_005thm.jpg
909807b88f5918c37449a1066008e319
647ee28bb79331284b3df0bb32d42ca1d2b595b1
2208 F20110109_AACRZP gopalakrishnan_j_Page_049.txt
36e98aac86b24d55237bc94d845e86c4
aaf3a56aa354bd94aa78fb1748914ad7b9613a2b
F20110109_AACSFK gopalakrishnan_j_Page_036.tif
527b9d008973af886110ee9ae0b36cd9
fa756984a01c35e3b90008fda1b6bfe115a57ba4
73720 F20110109_AACSEW gopalakrishnan_j_Page_030.jpg
290ca828307b90bd63bb558ee8519352
e4c88a7d829c58054f917b9d553150f30c7e4168
28560 F20110109_AACRZQ gopalakrishnan_j_Page_042.QC.jpg
554272e976d2452865fc58ac5728c901
e9ac06b7be07ae003312764fbf9c0984d46ad784
34020 F20110109_AACSFL gopalakrishnan_j_Page_081.QC.jpg
854163814e447fa16049a16d1bf61dde
7a0b75e94cd8f3953fb3c7ed4b53f34655893281
46804 F20110109_AACSEX gopalakrishnan_j_Page_086.pro
9dd945e2920c4e26385cf5d1cc1ec42b
1602aafecaf92405404c65961c74b181e77bc53a
1608 F20110109_AACRZR gopalakrishnan_j_Page_103.txt
c22ce82f2961b7aa42ff6c1ade34a7da
156c23728aa7463cec0d02bfbfe83575efcf02cb
143788 F20110109_AACSGA gopalakrishnan_j_Page_006.jpg
93c939930056bd58c59b2ddcb7fca5aa
3fd61329a24fa70117e3ddc268e290fe9c6be68a
42309 F20110109_AACSFM gopalakrishnan_j_Page_092.pro
993e78b8908824e66857f40a1b8dfad6
17ce9829efc9bc065f6522b3839770036941b2d4
56899 F20110109_AACSEY gopalakrishnan_j_Page_004.jpg
e46205b7c8b719e3600401ae65785bb7
d7274d37db7e9b71fd205342100fb5a858c7b919
81790 F20110109_AACRZS gopalakrishnan_j_Page_016.jpg
98f965b1adb2efdab6e8c8c3aac0f5a4
ffcbf74021e85ce84a3e74fc136f6219b543b710
143754 F20110109_AACSGB gopalakrishnan_j_Page_007.jpg
4f56084acc2ce91dec3d153ffee24cf4
ae69a455e11cbe5827c472322938e9b120aff653
2634 F20110109_AACSFN gopalakrishnan_j_Page_063.txt
10c3e94aef2c0ea64051962a1295a601
f09859182bd23bd9007e99672a0d0bab6bd130f0
8509 F20110109_AACSEZ gopalakrishnan_j_Page_061thm.jpg
f69dc482dc8b70524db0e18f3ff5f4eb
2dcc9147f33e5eab54b7c5cbfd5909666f536c23
9684 F20110109_AACRZT gopalakrishnan_j_Page_043.jp2
c41a28063fa9e9962abf2f3b0d304ab5
c1eeee96de484b7858f8ad4735b65ecf34986f22
36741 F20110109_AACSGC gopalakrishnan_j_Page_009.jpg
06b84e2bf1219ad0334b22adbc8fc8d2
5d9793005fee4ded12fd75c36febc01c891723aa
100157 F20110109_AACSFO gopalakrishnan_j_Page_097.jp2
a42f624c473f2fc82d50fba6d74df13c
2893fb5af0bd0ddbd1c81545022cf8e90bf15f30
28705 F20110109_AACRZU gopalakrishnan_j_Page_054.QC.jpg
5a3fbfac7b58599f2b025e89cf3fcda3
fc9f5b5e63fdff9e5a5dd83669cdb67ec7c53250
74591 F20110109_AACSGD gopalakrishnan_j_Page_011.jpg
c31e45bbe4bc7abcba202389ac4cf578
ffb8e412259c3281f9b1439c77e9bdd5b812fb22
F20110109_AACSFP gopalakrishnan_j_Page_087.tif
34a375923224785546fb4011f98bddf3
e0bcb9edca37949989ee6173b89fefbc2f8bed78
87147 F20110109_AACRZV gopalakrishnan_j_Page_032.jp2
71c7fe272efd8e4f79534cf309150d71
8168bd3906bca423672b8cc37b571f5a436d5de5
101744 F20110109_AACSGE gopalakrishnan_j_Page_019.jpg
6e6b41fa9e9e9cd323c231933fd4af62
6baad300d9cfa579defcc5c3872d14928f0c641a
F20110109_AACSFQ gopalakrishnan_j_Page_019.tif
b2ab7b1289086e0235e7cc1065d49bbd
4379bbb644e2fde3d7c39b67ba530debf72f723c
6585 F20110109_AACRZW gopalakrishnan_j_Page_016thm.jpg
0938e333cc809a689af900cf278e2933
c707c61d169e4241c7d6efc387c308b794f7de57
F20110109_AACSFR gopalakrishnan_j_Page_088.tif
17d0d71b9065f9bebf71121f673f76c8
eefea3d951e0826c0855fe85c07773091646616d
7046 F20110109_AACRZX gopalakrishnan_j_Page_074thm.jpg
919442c26b62e627ceddf721f86cc522
4bce53cce077eb3b52022c19f273afb7ffb2b471
94436 F20110109_AACSGF gopalakrishnan_j_Page_022.jpg
1711f76a8d5b8115b24ff5e75b0a3a1b
c469c2ff58df5022235fbb9b82fd7c5789c68542
41789 F20110109_AACSFS gopalakrishnan_j_Page_054.pro
006f1ca684cf70b0b29da6a66a25c98d
75531e676f5c05ab96548e490861ca47317c15b7
516 F20110109_AACRZY gopalakrishnan_j_Page_036.txt
86f763bc2a50070d45362b303992d486
6d8b4c1d0a905a0c996f4e7e8375cb4a704893c7
98826 F20110109_AACSGG gopalakrishnan_j_Page_023.jpg
a91bd9c147adcf20ed8c7ff77d62e4f7
69effe0d00c47c3f28bcbda9e79124f3a1a9ad81
7346 F20110109_AACSFT gopalakrishnan_j_Page_007thm.jpg
34c17299f296e401957b005dbc1c667b
daaa45f67e6e02821057cf031aff34a6a1354bab
69461 F20110109_AACSGH gopalakrishnan_j_Page_029.jpg
12d008b9adfdd22bec2504f2b6ddca4c
be91069da341f8588b2a306d5198d8083628c97a
44403 F20110109_AACSFU gopalakrishnan_j_Page_073.pro
933eb331da89cd2c837f2223856ef62f
900ebf86c35e7d325a5fee5a7b0d5698487b0ebe
25274 F20110109_AACRZZ gopalakrishnan_j_Page_062.pro
e8609df50b6e1a45d208c2b3be81990b
b466535b8a68b16b807ed14fd83f36577165c155
72272 F20110109_AACSGI gopalakrishnan_j_Page_034.jpg
be1630407da61197b710e0decf357d0a
428c6ce18a54a836cc5cb30074c65fcaa3729021
7052 F20110109_AACSFV gopalakrishnan_j_Page_083thm.jpg
b9e06941992336ecf5e359549ccdd065
06ee9dc0769a54b1c15b6cb339de06bc556f07f5
90309 F20110109_AACSGJ gopalakrishnan_j_Page_035.jpg
7145ae01f376a20077936382606eb0e5
6b676d7270cc5f664a1470adf48c2678ec9a3e65
185211 F20110109_AACSFW UFE0001189_00001.xml
30eba05477e6551cae81a668f22dc1a3
d8269adee3173bbbd76201e5c2a0384ed5044da7
91705 F20110109_AACSGK gopalakrishnan_j_Page_042.jpg
43bb63f13d436a8657ebca32152ad439
65076186f6add66aa19746ebceaa6eb5130a1bd0
80972 F20110109_AACSHA gopalakrishnan_j_Page_076.jpg
39fc91664619b759b90cd4a4a5983f91
1b541876b180f9c44d864d0afb56b79c3609f108
8548 F20110109_AACSGL gopalakrishnan_j_Page_043.jpg
ecc0cdc054c5b9b7893f96a7efbae3a3
ca8b1e35d5b021e76ce668bb4d82982888b51efd
91483 F20110109_AACSHB gopalakrishnan_j_Page_077.jpg
b677a11e69fed3992c08696cc17d0ebf
bc176f71e52a76719c92fb29802937e37829259a
111874 F20110109_AACSGM gopalakrishnan_j_Page_044.jpg
e4faffc795e47a3593deaa0360498d54
d515705ed39fabcfa060b6156fafab22508a2cdf
5614 F20110109_AACSFZ gopalakrishnan_j_Page_002.jpg
8deb862224880f155abdeebd2eb41884
502fdf37fdc9d2d98c6304064e95929f639b93de
95793 F20110109_AACSHC gopalakrishnan_j_Page_078.jpg
40ddae81955593fe21f62c82ab247954
1b3e288cd86dfc8274081d79ee5ca5cb075081d7
95654 F20110109_AACSGN gopalakrishnan_j_Page_045.jpg
a44ce7913a232bbbe9c1ae08fc6b66dc
711734d0622f5c04dc1a27c8b01d58104ea79e34
114658 F20110109_AACSHD gopalakrishnan_j_Page_089.jpg
91fdabab8f73707c321b8c0938e260c3
0df1db01e03b6866982e82748f5dd331921ac792
73737 F20110109_AACSGO gopalakrishnan_j_Page_047.jpg
8cd9abd5deb2419ac268763a8e127ae7
f970f2629bb3eed239a212044639fcfd80677314
106524 F20110109_AACSHE gopalakrishnan_j_Page_091.jpg
f85a2e802424e9c259a2ed61ad8be1a6
8d8abbbeea85371ca95fb1f7a8d8a71dc32ef21f
84633 F20110109_AACSGP gopalakrishnan_j_Page_052.jpg
56e876049f7ee801e77475b07ddad628
de2ddac9689802cb31cf29c19473d9f7c8f56bdc
83806 F20110109_AACSHF gopalakrishnan_j_Page_094.jpg
c33f2649a44575b9cbd7367829cc6465
1838ed7c1afa31f38f1106a0d08b127dac55d55e
77516 F20110109_AACSGQ gopalakrishnan_j_Page_055.jpg
44a1ae2baf8aecf5957566f72973177c
539dbb1106da7f06f3cbbab363e1d84474c9c0ce
97539 F20110109_AACSGR gopalakrishnan_j_Page_056.jpg
0ab31b68c66f8f85c36c12e61ba9dad3
af3730b33345f2e44666f0db634c0fcccd1dbb0e
12679 F20110109_AACSHG gopalakrishnan_j_Page_098.jpg
dce5ed2b777b1ae33979dc622a09077e
432502f96ca92d5d70a4334405e174e86ee77d24
93941 F20110109_AACSGS gopalakrishnan_j_Page_060.jpg
c6a4f906b9fc1ccf6cea6a84e354016d
9d6ecbfa8c6eabb12a712ded38d8f119a9371862
57472 F20110109_AACSHH gopalakrishnan_j_Page_107.jpg
7b463f794317431c901edf289df041e2
2e3e43b367f48ad8452ed790617b39c10c994dd5
115339 F20110109_AACSGT gopalakrishnan_j_Page_061.jpg
ed7aac87efc3526f56303a36ebb60030
ada8130b513635e4d24d5afc8efb9c8397263e1c
78373 F20110109_AACSHI gopalakrishnan_j_Page_108.jpg
98ba07ed21bf0c60fa458b03c225a0ec
6ccc7d739686dee4ff697b59256e9c9a2a3e726e
81307 F20110109_AACSGU gopalakrishnan_j_Page_062.jpg
49db46dbe414ecc4276feac183741eac
32c411611834c7149065b5d4bd1b673d297b91b2
63316 F20110109_AACSHJ gopalakrishnan_j_Page_111.jpg
35019ff018a75363be00b1cd9b935998
83cfe8efb8c591e43729e3db55411d2954402670
127085 F20110109_AACSGV gopalakrishnan_j_Page_063.jpg
8de02b6f3a51e4e1a41813782145b4bf
eb2767a5bd8180f4057812af0e872042bcb2b2ac
107947 F20110109_AACSHK gopalakrishnan_j_Page_116.jpg
dd49f8cc9cf0bb5ef88f3de18c30bef1
5e96b4fc84f84ff928ce2f2a509ad22016b036e5
133286 F20110109_AACSGW gopalakrishnan_j_Page_064.jpg
e43886a22ea635c9b25932cc616d095d
14b25766f1a8d76ad64049cd497a872bd7cb9f70
844930 F20110109_AACSIA gopalakrishnan_j_Page_059.jp2
c4c9222cd9d47c32fd2656dfd4473e36
5f354ed7632e3abf686fa5f3e20f490e34753409
46048 F20110109_AACSHL gopalakrishnan_j_Page_119.jpg
6d9e3f9a6cb40f5c3955e775a522d924
f59bcf5d93750917551a068bc1d34f2ec3d88085
99754 F20110109_AACSGX gopalakrishnan_j_Page_065.jpg
feec037fd04aad9da77cf24d2d406a5c
7573d271bf973895b602e780f01a6f96604c75c0
116911 F20110109_AACSIB gopalakrishnan_j_Page_061.jp2
35b408241c77b6289ba6aff948b54222
ec0cfd6ae507c7596419ceced4449b39ea617c27
23845 F20110109_AACSHM gopalakrishnan_j_Page_001.jp2
d9578d39673264c4eb3698ba89aa0ff5
fa987130b8f6743118db068b629f5fabc56b6fa7
109252 F20110109_AACSGY gopalakrishnan_j_Page_071.jpg
5b89eb880b869d388ea6254242339715
fa3d1e1ec33f2d87c297d9f7b0eda339801ae686
799105 F20110109_AACSIC gopalakrishnan_j_Page_062.jp2
5911f0856666c73e27ca5d68fa6c3f74
e9ff83520611edaf6deeaf581456ef358b8c85c8
636636 F20110109_AACSHN gopalakrishnan_j_Page_009.jp2
71b6314fbac8d98e4784e17aa2096531
cb0222eef6cd0aab31e364e8fedd3c6a0d8e239a
99016 F20110109_AACSGZ gopalakrishnan_j_Page_072.jpg
a5ec4340b69d059b80039ec2fd860826
bdae8e9ba50d2586984ab61c74b6f6ae58721399
105380 F20110109_AACSID gopalakrishnan_j_Page_066.jp2
031db82cff0a5d1b3d17b2b259d165f0
e6b281591dae6d2fb5dc144ef8bbc78faf32d74d
76789 F20110109_AACSHO gopalakrishnan_j_Page_011.jp2
e98131e38d9b07f3e2bcca2ca057e6bc
aad96a32db993c921012efc9f0ecba5f89470fb2
96775 F20110109_AACSIE gopalakrishnan_j_Page_067.jp2
8106257784397caa2d256e14c642e0c8
33e0fefce8ea091769638ca53e7e9fb0858091b8
96594 F20110109_AACSHP gopalakrishnan_j_Page_015.jp2
4137a78d6c4c490c49317dc15f76cda2
7e18f9b2033b16938a2c7f9b6ed57196ec342f88
118515 F20110109_AACSIF gopalakrishnan_j_Page_071.jp2
124b0620516905dd27a18fe9b41d26f3
feb4f9fe42c813ad86d56648b08bbeb0d8197802
104690 F20110109_AACSHQ gopalakrishnan_j_Page_023.jp2
7567da7da092c6b557fd4f42bbe6745a
aea1358d643d0f533d6616af80c2a49c7a1b9fe9
34408 F20110109_AACSIG gopalakrishnan_j_Page_075.jp2
a898b5b7eed4e51fcca8cae215e975d6
5edd7f1fe5a213c55aae7b5f1c6271b38455631e
108273 F20110109_AACSHR gopalakrishnan_j_Page_024.jp2
7e06e81c2342add66413603838c1666b
d517a33cc8aa885fa1f00cdfdf99a2bbd56de0c0
766288 F20110109_AACSHS gopalakrishnan_j_Page_034.jp2
84e1688200bc2af81625f39a28acf374
e867942fd5fd544d929dc0bce78ee6d9cab7811f
754712 F20110109_AACSIH gopalakrishnan_j_Page_082.jp2
15cb0a94f4e7c940053a9afa00ef4638
0602115bffe24a21935e3c0a50d67d9a6a2dc461
335916 F20110109_AACSHT gopalakrishnan_j_Page_036.jp2
a78f9abe656913882ba4e211bbc18913
1b8cd0f2b3c987ec6ee4ee4f34e45c92fcb80edf
79645 F20110109_AACSII gopalakrishnan_j_Page_083.jp2
d1e1473c9b39c407bdbdd8d9e33c8cb7
95aa71b0e95966cf0fe3ef9cb0264716340f26d5
728523 F20110109_AACSHU gopalakrishnan_j_Page_038.jp2
f3460278f016b02a5795a7021ae673c7
ce577ae6e779c2670a330a890ef773321811e768
104296 F20110109_AACSIJ gopalakrishnan_j_Page_085.jp2
ef754d8ca5027212286118cb8ff4cf45
15a2a405a02e206e72b700d5a2f7b317db97af9b
90919 F20110109_AACSHV gopalakrishnan_j_Page_041.jp2
6348aacc9de3d98c6c01f33c5c5bb74b
7ecffcdad8f331e113419332493826ce1d2d0412
97194 F20110109_AACSIK gopalakrishnan_j_Page_086.jp2
793d14897a613d12212910fc2d23f8f8
32bf432bc24c4a4703f50ac99b096034e8f52a6c
110807 F20110109_AACSHW gopalakrishnan_j_Page_044.jp2
f89e953ff52bf00d5fcd210947a1b335
28c23b52821245ddaacc3c4d7f46040efb0913e1
98822 F20110109_AACSIL gopalakrishnan_j_Page_101.jp2
7afe94c21ca19841bf4efd51b20ce790
f3257f5af089bf4fff5d39e992b7e4ad64b11e64
99647 F20110109_AACSHX gopalakrishnan_j_Page_045.jp2
f460c9a9ed9f4d189697adfc7e231b20
d0f1b9721e74a82b8add92fe2453dde8c3b4a74e
F20110109_AACSJA gopalakrishnan_j_Page_035.tif
6ae7d6be5248fcb40e9c189b32e8a10b
3da4e566b759f0a7ef4ca0cc0759bfa240fdad5f
87107 F20110109_AACSIM gopalakrishnan_j_Page_103.jp2
1f2a43868c79ed73500af8c5bd89f35d
c1f1caa5ba2e77c04957ef652b7c717608e65663
786786 F20110109_AACSHY gopalakrishnan_j_Page_053.jp2
7f25a2e74cf06d7d2f20d5b1a6acba41
5b414c378e6a97521eaa56be5fd34bacac59fe12
F20110109_AACSJB gopalakrishnan_j_Page_037.tif
8aa8b651fc7824576e4919a2c0e4886b
b52a9efdf56ea03139011dfcf95abb1138c4b8c5
55649 F20110109_AACSIN gopalakrishnan_j_Page_105.jp2
296aa99eab950dbaf67a048efa24aa88
bc1a8275e53425f88b4a75c408280d3141a69753
92164 F20110109_AACSHZ gopalakrishnan_j_Page_058.jp2
91dbab8f5a8282c4ccff397a19f5d609
66b78ceb9c3f304f9e7716aaab0c53a0953444db
F20110109_AACSJC gopalakrishnan_j_Page_046.tif
ff5de1eb6a82523e19fa508f83c0936b
bd0fdd7e0c0e1b8cf371a284949580ace087f0cf
77315 F20110109_AACSIO gopalakrishnan_j_Page_106.jp2
36506ac0bf8d1fa701e6c908e5b4874d
323d05403852e3116b8c70aba478f5b0fa9e5146
F20110109_AACSJD gopalakrishnan_j_Page_047.tif
30316aa81247991b0ea6492542775580
88ba95ddea8b2fa98c2dff63d3715cbee5b19ad3
71625 F20110109_AACSIP gopalakrishnan_j_Page_110.jp2
6219bd8ef00ab117f0baa63d31c95869
ea89969ec3413a516e28095e84503787eb91be19
F20110109_AACSJE gopalakrishnan_j_Page_049.tif
7cea85e297feb323b265b7e5142b703a
8ecf9cb631b6b8bc7ec36c016401d9d9482b97c1
25975 F20110109_AACSIQ gopalakrishnan_j_Page_115.jp2
a2089bd02d18dc2ca3eea0352f786b35
ba68395b3031964fb3a483e73af009674fbf9aee
F20110109_AACSJF gopalakrishnan_j_Page_053.tif
bd6f3505754223355781ad912bde1e13
02cb880bb3655bcdab9fd1d7ab27bace5a7d5f16
F20110109_AACSIR gopalakrishnan_j_Page_003.tif
d22f8effc587073101f2046244452f6a
9e4d2107f2848fbaebf3d2e80893a7428380a9fe
F20110109_AACSJG gopalakrishnan_j_Page_056.tif
fd3bc0c46739c53e58693d1597ccd41e
ece8471a79cefcb0df04762881ec5932bbc10144
F20110109_AACSIS gopalakrishnan_j_Page_004.tif
355d2f8adcae3987dcac6abf48e29eb2
2a1841c1df3d0d8635c802385489a9ede09e52eb
F20110109_AACSJH gopalakrishnan_j_Page_057.tif
cfbc71cf5a4d91d861ef808e29646168
12414f18619908008e542be22b94aaac384402f1
F20110109_AACSIT gopalakrishnan_j_Page_006.tif
b2f932922607d3d8a6604a73837abd5e
bbabdbf4f59d94478bd8dec3ac8c14b0a48805c2
F20110109_AACSIU gopalakrishnan_j_Page_018.tif
42fd81465c732609231c50b62699158d
c9698279c448cd6aebc9c41050c5549ab04c591e
F20110109_AACSJI gopalakrishnan_j_Page_062.tif
298845d4fe03b18ba52a40b37882f19b
094c555ffb15ac4571af2296b0b3981b94472121
F20110109_AACSIV gopalakrishnan_j_Page_020.tif
a0a4c588a75468ade520b13ba8efb02c
fda5c047d6b009eefde3f383985c2561dbd28a4f
F20110109_AACSJJ gopalakrishnan_j_Page_066.tif
8f5c4bf89858b2d9f561a337a3dd8194
5fcd6b716259f244159e84934d4a1894070be9be
F20110109_AACSIW gopalakrishnan_j_Page_022.tif
4daae3e037fb2fb0bd84b8492fc133dd
590188d1c0fdc5e0b0d611c239392c0e86a43556
F20110109_AACSJK gopalakrishnan_j_Page_067.tif
40cd80d99347c85538296b361251a59f
acb156cc96db067413213936245b18d0bd4c1b1b
867 F20110109_AACSKA gopalakrishnan_j_Page_003.pro
82437476d0285054db97671b44350dd8
83ffe3a235c7e426dc92db9b3ba19af950b5de16
F20110109_AACSJL gopalakrishnan_j_Page_068.tif
2929b6b694cecd03712748fbe7a90d33
bde023b0255acc8c7230e2e547196b51b4e678ca
F20110109_AACSIX gopalakrishnan_j_Page_026.tif
0ef47618c2d0ba2a76b073b8702fd081
dc8fc9ce8c22a73e699bdcaaf70113ed65855615
82848 F20110109_AACSKB gopalakrishnan_j_Page_005.pro
bc00e959cb871b533002d45c3fd7ccf4
7939d0f9470aac05d8c9561a12cd8db0197eac58
F20110109_AACSJM gopalakrishnan_j_Page_070.tif
87b375abcb146e465914b27206f317e1
4ef7ed409e07d99c4f439b68151c81c43a60b59f
F20110109_AACSIY gopalakrishnan_j_Page_027.tif
00695566edf77658bfee7066c8b8cfbb
8f0ccdb16f722185de536cf021b3191070cb5d45
108442 F20110109_AACSKC gopalakrishnan_j_Page_007.pro
81f4378a6f5ac15dc707bff5e0353777
e45413f7fbb03ff0f013d0ba208064ce4b3da21b
F20110109_AACSJN gopalakrishnan_j_Page_074.tif
8c2413aaa76f9b3d79e1f7abdc0291a5
b07ba9c33ff695c6a4fa0ead6a569a6e76298510
F20110109_AACSIZ gopalakrishnan_j_Page_032.tif
244617522d41a93baa3971de04f9bfa1
a53589e9c4a9cd7469a108ca51a787a7737df566
16733 F20110109_AACSKD gopalakrishnan_j_Page_009.pro
b6c3c0b256e35ff40be390336650717f
056bfcff56c7717f31b5ad31dfa5a9809c603d55
F20110109_AACSJO gopalakrishnan_j_Page_075.tif
f72b68388227e1b600306f37ee6f8ac9
de0a1105655e56d0740374aedcfd3ca14cd0027b
52984 F20110109_AACSKE gopalakrishnan_j_Page_010.pro
b3a60847d86f4b5eca39add86af1e7de
88283444ce97156b1a9418e7f735c46bcd57206f
F20110109_AACSJP gopalakrishnan_j_Page_076.tif
921def06d5cd09a9bde2045bd2c7f999
7f58375b611d8e93ff9f55795a6dac1e26429567
33769 F20110109_AACSKF gopalakrishnan_j_Page_011.pro
cbe58932b5b8b72628967d4ed33c0974
98ffb4ca5605d1e85a2a027708abdb722504f43c
F20110109_AACSJQ gopalakrishnan_j_Page_086.tif
e3402bbb33743a833c6dba6ca661d05c
2ede639661d69b6ea81fccc3eb77544bbc9a3c79
44085 F20110109_AACSKG gopalakrishnan_j_Page_015.pro
8e8e29b3b64d61b24f3b020627b29ab8
630a12619d0828bced10ec63be1dbd92d5ef8493
F20110109_AACSJR gopalakrishnan_j_Page_089.tif
f378a3677851ae631bf1765e3398713b
f0aefcd42050edb679227177e719333139d2a3cb
40216 F20110109_AACSKH gopalakrishnan_j_Page_016.pro
031ad92e0d93ae4f9ab590a947c4b510
1d9ac7e58d3a84616acf028f5a51a0fb56243643
F20110109_AACSJS gopalakrishnan_j_Page_090.tif
47772689207424b4120b06bf5a2951c0
a03c8f10e33d0d449ad6d8ef6ff2aca75c7ea08d
36495 F20110109_AACSKI gopalakrishnan_j_Page_017.pro
e6540e417336dc951cbb9ac66d107f3a
d798e6fe9d9b31648bb3dcedafc06ea3806891c2
F20110109_AACSJT gopalakrishnan_j_Page_095.tif
2b692c643f5953ca47b7fa9035ee09f3
12e10686751e30af88012504d5b7179135a53fda
F20110109_AACSJU gopalakrishnan_j_Page_100.tif
3138bbef232e8840776d653bdcd03c85
97180f1cd43f122a7237918495cabdde9b730824
49791 F20110109_AACSKJ gopalakrishnan_j_Page_019.pro
86d58e421d8c5b2a3c24cabb5c2e4775
8d1a428afa704592af5e6dbe1520d3d4f423e8ba
F20110109_AACSJV gopalakrishnan_j_Page_107.tif
126f04b03c4718ddce7c7957851bf08e
f2c14f41abbae560360013a9790f99d263e7baa8
34319 F20110109_AACSKK gopalakrishnan_j_Page_020.pro
5cd3636647f88c810a7c79d482245786
569a2a25e2f65183e43917e0eaee3567007c9e63
F20110109_AACSJW gopalakrishnan_j_Page_110.tif
2090143d60deda3e54232f14977bc332
107f51ae39ee0ce2c4fee2a838c0b94c84f26d31
61266 F20110109_AACSKL gopalakrishnan_j_Page_021.pro
35fbee1c19d441b58fadb43f654ea5c2
3eb92fadcb4793edfd8c7c753d4a4a1fa1e41410
F20110109_AACSJX gopalakrishnan_j_Page_114.tif
38adf2d3e094d24b770a2c5e594e865f
699d75a0fdcb392ef15344a0a354671e4f7858ac
68989 F20110109_AACSLA gopalakrishnan_j_Page_064.pro
a507e3e0632ebb96558029de4e6bb472
ff7f2f62b5e92b9349d70508222ff6d7872f9449
47611 F20110109_AACSKM gopalakrishnan_j_Page_023.pro
d9a4b847d8634f3542eaef68657bc028
1133295e6fc6a6bec276243f081135e11de79905
F20110109_AACSJY gopalakrishnan_j_Page_116.tif
3f18e0a6cbc3d5604d5d26147bf3699d
66cbf9538896f8681910be1f5afef51672138765
45719 F20110109_AACSLB gopalakrishnan_j_Page_067.pro
f25a0f59124349cb92b7a32238d1cc0c
c73e96bf5126f1f77cfe037554d531664a16a88d
59607 F20110109_AACSKN gopalakrishnan_j_Page_026.pro
4e1ed28b58f4574348b3859189055e71
217ed9f619e2a73032f90c92df404e1481f9efa4
1521 F20110109_AACSJZ gopalakrishnan_j_Page_002.pro
da801ba5296e7c2ce1e9a9d6951c6981
461f7f718a620c63624fa441b680b2da4cf6b290
14329 F20110109_AACSLC gopalakrishnan_j_Page_075.pro
5d4ce032ab6291f28314d59b6e6476c7
5735ba9664dec7b37283a93bb695626fc2fbf22a
27035 F20110109_AACSKO gopalakrishnan_j_Page_028.pro
24223d9cd32cecd310d7c80d0e8d81f0
57aa03de09ec2cc367f8f54cee03e0d5b5f3276e
37203 F20110109_AACSLD gopalakrishnan_j_Page_076.pro
81a1749786f3c0e2957212bce5cccf81
99edb8a7d66d01ec8632be3f15f59672d33679ed
27150 F20110109_AACSKP gopalakrishnan_j_Page_029.pro
e82728db4f1cf0d5823e660f956b6a8b
8f7f2b9a9045f77c130471fd4030ef3c3426ab8f
42562 F20110109_AACSLE gopalakrishnan_j_Page_077.pro
211f6a90cc940d1e67094d2f21294861
e7cb594c9fc5cd550402675a61cd741a6ecc6b73
37981 F20110109_AACSKQ gopalakrishnan_j_Page_032.pro
2798bcaff8d828f7ccd40035c5c96aa6
8975551c9f49a628e15b34a33c9905d787adee5e
38231 F20110109_AACSLF gopalakrishnan_j_Page_079.pro
acaaa0b8f0f8a3bd29fe85ad07be7547
b41361ad50a41f5263bce778e5e295e40b84840c
42716 F20110109_AACSKR gopalakrishnan_j_Page_035.pro
03dc1e15523fe436a89392c9f973d7af
1d182420d754c1cd120d99d38a670699eed93ae4
64792 F20110109_AACSLG gopalakrishnan_j_Page_080.pro
255059299b8140855b890100663d0368
b68b6c6018c720d6e17a2c9328ad8592a7e58f35
44251 F20110109_AACSKS gopalakrishnan_j_Page_042.pro
00b2442d534d204d65c0a83217f1033d
d2e795b8b2550592184a347898160ce719e7b27a
66470 F20110109_AACSLH gopalakrishnan_j_Page_081.pro
bc7535d8a3623ee6071bd9388d385a94
b71e732be93390ee51803b72ea160f413f9f9456
53891 F20110109_AACSKT gopalakrishnan_j_Page_044.pro
fe0d2138f266211bcb1ea4cbd2e2034d
e114ea21b274964f4d93d9babe856be317cd17cd
46455 F20110109_AACSLI gopalakrishnan_j_Page_087.pro
4d8a6f570dd92ad5d081ea4720a92405
e1c1069a70fed61abd0c2b1a4e074c6b136c99e5
27578 F20110109_AACSKU gopalakrishnan_j_Page_047.pro
9a6dd4e57986b6e7efa93072f5cb25ac
6fa527e8319e102d35980a0485e4a53483b2c707
56281 F20110109_AACSLJ gopalakrishnan_j_Page_089.pro
2f6200777a5407eeb0c7968dfeea4466
8007c1e65e6d56fd266c986d9722ade9a1b1b29f
38577 F20110109_AACSKV gopalakrishnan_j_Page_055.pro
c787a4ca15ef9d2fecf2c44c3c4a060a
a670be5c72eea622a4cec08d147a7427e36f45b1
49202 F20110109_AACSKW gopalakrishnan_j_Page_056.pro
39a5d94b44e9ed7a11048a145681ddb6
a9906da143bbc0d0b1f420755b3fc6b5e5aed712
51426 F20110109_AACSLK gopalakrishnan_j_Page_091.pro
f79d9439c0e91b0314d80a5be410a5f7
12d6e609befc8b27082e08650f3b668d7b5e6d54
32647 F20110109_AACSKX gopalakrishnan_j_Page_059.pro
403685a9b3606afb5b1b25d7d6331dcf
1ceedd1c931f1420ef09f6a0a292c997c5ae762b
1178 F20110109_AACSMA gopalakrishnan_j_Page_029.txt
a74a3e728250d67e3a350b4a3c36b22c
37dbad4dfa76d80b7b7fef512ef43e47a074caca
36224 F20110109_AACSLL gopalakrishnan_j_Page_096.pro
920b4b798a71e18c3ade3606f9762c1a
342cd359459b95c03512964c9b75a96016220460
45864 F20110109_AACSKY gopalakrishnan_j_Page_060.pro
ef5b0a7ff2e7dd1faa45c4b6dd5f29ae
31cb8815ea8dc152112023202710ad31859bbe68
1427 F20110109_AACSMB gopalakrishnan_j_Page_030.txt
f85cc8f29cbd6546dfb83af4f08ebf57
6d6012e89cafda905c0684ba74752f580e945987
31234 F20110109_AACSLM gopalakrishnan_j_Page_107.pro
35600e7e2534e7dfb009cc7753919241
96539e976c8b04a20dfbbe9e305e5dacf8897510
56849 F20110109_AACSKZ gopalakrishnan_j_Page_061.pro
59c3993c18489c6e81009d39b05998a8
a7ce6aba532cc657037f732c2a8079eae5a4ea2b
1276 F20110109_AACSMC gopalakrishnan_j_Page_034.txt
6c5c569819e490042df77a80a26c5fbb
b8ed1526c84d2e2b472a9a2d0c170c7ed8939630
41875 F20110109_AACSLN gopalakrishnan_j_Page_108.pro
4383e52cbb80fe541916c557ab217837
be26eab640f6b1ad8c6e59dcb52febd2ffdcea64
1167 F20110109_AACSMD gopalakrishnan_j_Page_037.txt
00d49805820d258e2120754365caf966
83babc9945d8561748823977c47273f2a6a7a058
12167 F20110109_AACSLO gopalakrishnan_j_Page_115.pro
a0121f36bef79205c257cdff46fda650
acc141bce1e1bb5916da43a9152eb410cc26e29d
F20110109_AACSME gopalakrishnan_j_Page_041.txt
e4b87c2cbc82c44c33f9980e96a46139
5592c124a777cb901aa786a5cb1761682d7e0179
136 F20110109_AACSLP gopalakrishnan_j_Page_002.txt
2baa994ac0957ada92903a4c7c6ce28b
aac4a92ffd7677cc8a203fe035b6900fbb9b0a29
168 F20110109_AACSMF gopalakrishnan_j_Page_043.txt
cc63b48b0693d47c0733c78c75c0d144
4dfb2fe0d516411fc19bc101d96ac136b82d75cc
1104 F20110109_AACSLQ gopalakrishnan_j_Page_004.txt
4275156abd181269acfae6822563b611
46e5e66db4e9fb86ef32a69c46a6b2b83615f648
2513 F20110109_AACSMG gopalakrishnan_j_Page_044.txt
1286d377cfab9cefb7a229c71ab5bef5
30a349828433d2f2b3aa2268bafdce905053d981
3476 F20110109_AACSLR gopalakrishnan_j_Page_005.txt
8cdf38bcac6a760c1c1f040d949e2f58
24f9d848b4b03c0ac23ebd9871ddaf63047ed61d
1639 F20110109_AACSMH gopalakrishnan_j_Page_052.txt
187b4e36d65621384de50ad632767b83
7d4ffe92fcb74e715d47a738a632ae3a016aad8f
4752 F20110109_AACSLS gopalakrishnan_j_Page_006.txt
e01bc56b3e38c588482200932271b9ec
2ce7b50e2f0603bea3ca295245ede250e7ff9388
1180 F20110109_AACSMI gopalakrishnan_j_Page_057.txt
c8ca3c6019ae1584378ecfde44f728e5
3667c5b2321cab795fe0dee5a27e150aee426ee2
4419 F20110109_AACSLT gopalakrishnan_j_Page_007.txt
ff21496df03afd8879d5d12b5a1e9f66
5c00887a5c0470f8ce3f7047c8925a740089dcfe
1372 F20110109_AACSMJ gopalakrishnan_j_Page_059.txt
ae6094894b8b37aff40cd15a9ec23fb1
34875dc4c9b9202bf4f70c878b6922181f1cbbe8
1622 F20110109_AACSLU gopalakrishnan_j_Page_008.txt
5d3d9c1f93aa1c7997638b7ba8921d8d
31e4501e5cd22592079fcbdbf819a41a026a43e7
2842 F20110109_AACSMK gopalakrishnan_j_Page_064.txt
c14625fa7772f8d176eb53f9b0a60197
30f090c3125750524b470418eba7c64daeed96ff
2116 F20110109_AACSLV gopalakrishnan_j_Page_010.txt
3cbabc8d383392761faa2b38a944c4eb
68da40429894d17c80ed96655ffd6960caeb440d
1624 F20110109_AACSLW gopalakrishnan_j_Page_016.txt
7d4def695e64331714f5962452e3e93f
d465dbc3cef9c6a2419e6bc5219ae2a1238622a3
11432 F20110109_AACSNA gopalakrishnan_j_Page_009.QC.jpg
2ccbd1de1e92124581b100da264ff75d
861ca8e5c6092254ab8c2c6ee40d139caa5c1ab4
F20110109_AACSML gopalakrishnan_j_Page_067.txt
244a28ddaf92369a65592299da3fd6d0
a5be0fea876adb271ebc731db30eac50f6cac492
1546 F20110109_AACSLX gopalakrishnan_j_Page_017.txt
aac637f733ebd8eb34be07bc6b8f0edd
0ed9ad7dea22feb3c7671d197455ceca4682169c
5991 F20110109_AACSNB gopalakrishnan_j_Page_011thm.jpg
18b1d3dd58884c95da9006cab7e44674
cff80523e709a06ed3ca99ab3daf0d1c0da00b6f
643 F20110109_AACSMM gopalakrishnan_j_Page_075.txt
e69a9e28982575d05a3b471e17a66125
4038549673469311151b2cd38b5b2fc3cac99c8c
1962 F20110109_AACSLY gopalakrishnan_j_Page_022.txt
7623a19bd789c1a8705d2b579d3b00f6
cb79746b49e9ea5c604ea2cab133bb8b655d8b1a
7928 F20110109_AACRKA gopalakrishnan_j_Page_022thm.jpg
a8b6f2a37f33a16f01c698c2af40899e
f17f0ddae59159ac0dc54469deb9b123a54470e3
19786 F20110109_AACSNC gopalakrishnan_j_Page_012.QC.jpg
b9a4f10be45cd14546bf9cc9d44353b9
54712058d54dae3825e119728dda40f4b03bc1d5
27008 F20110109_AACRJL gopalakrishnan_j_Page_118.QC.jpg
38e464d6d097bdb3b540acc1e97fdbaf
df4139c00db7528875c572d4448ba2661cdf2174
2641 F20110109_AACSMN gopalakrishnan_j_Page_080.txt
4647927920c78bf8fd954d9440ce3b98
09bae606c376f826c496c1e3984babc4c257fb17
2434 F20110109_AACSLZ gopalakrishnan_j_Page_026.txt
7bd687060875b7ad83b6b559e7de0ebd
d7d1d444314dc96d37dbecdb76838978ef52c552
810562 F20110109_AACRKB gopalakrishnan_j_Page_030.jp2
a7185e40c1d6122ad5b258dfa672c674
1de0a048409a46b8a6c0844b82d46f43392208e2
7807 F20110109_AACSND gopalakrishnan_j_Page_015thm.jpg
eb792c0068b73c9e110db8fbe940a4e4
b675592f6b95b937e67973ebb6125a346528ec30
109649 F20110109_AACRJM gopalakrishnan_j_Page_070.jp2
4dd044273dc46c88863f67913ed2508b
f1722b1ed459c45c0e8a9997ffedaf593edbe22c
1742 F20110109_AACSMO gopalakrishnan_j_Page_084.txt
6e10acc8fe36b6ec7a6c136d89f5318b
b535610f1aa76bbef4b29751779ddad75cb0970d
F20110109_AACRKC gopalakrishnan_j_Page_054.tif
5976988e9afed1b41d4ef650d76043ea
2b484ec383354685b8c8a1833ddadb77b966dbcc
8455 F20110109_AACSNE gopalakrishnan_j_Page_019thm.jpg
f7bcbc65363a051222cc62e2dde364ec
170c8281712a08626be6edcf92d23ad757091894
77445 F20110109_AACRJN gopalakrishnan_j_Page_114.jpg
5b19e273fb11d55943bb94cad2f1fc0d
15afc94ad37d19a997d0df5a3487a69f63a81be9
2138 F20110109_AACSMP gopalakrishnan_j_Page_086.txt
b22988fa15fff1b9f69dd0acf89b4a98
f5e60b8d31415e2e30fa06bce03658621aa8eba0
7937 F20110109_AACRKD gopalakrishnan_j_Page_084thm.jpg
cef1983aadd00869189b18d5a4b2f67e
4578b429f4af91ea7569eba936ca9deb922f0383
24255 F20110109_AACSNF gopalakrishnan_j_Page_020.QC.jpg
ea4a2458b4948f2f853b8a9ef1c04639
95746700202a81817950b51e0f92389ece5cae49
95850 F20110109_AACRJO gopalakrishnan_j_Page_087.jpg
c288a06766b05583a4e895b69575dcdc
9f7f8014880c30fdaa3f5facc54e6b88fb290e50
2435 F20110109_AACSMQ gopalakrishnan_j_Page_087.txt
c7c76f5015f2d14a7d55abd5fa8b5c1f
784a45bc5179035c74fc1d38ec3ef11ddc409507
F20110109_AACRKE gopalakrishnan_j_Page_071.tif
6d0b7f32dd914d85b1339d315f0e82a6
7413021e17edae91344f044b4c5b52c03c6ba36f
6567 F20110109_AACSNG gopalakrishnan_j_Page_020thm.jpg
bd09448c53cea39fffaabbfacfc6155e
868b40c54a63ce3d1714b46f8fa7898869f505a6
115187 F20110109_AACRJP gopalakrishnan_j_Page_090.jp2
c821f10494c4ab7a78486f74d3662af6
dca9f45aefa682c3cc5b621cb07870674c5ac648
2255 F20110109_AACSMR gopalakrishnan_j_Page_089.txt
0110f802365cd69587e5cb661d1f71b7
da01cac8302fbcd98a46c47e936e009f8316a874
79781 F20110109_AACRKF gopalakrishnan_j_Page_020.jpg
02d8eedcfa8b42c729c6772eecbbfe5c
532e99cf5c183180912e1e3648c331112e653e90
32422 F20110109_AACSNH gopalakrishnan_j_Page_024.QC.jpg
b7160b55255570ac83088bd712c5b27c
47d26834c5788a581ca441b83d29a6c235670e2d
7733 F20110109_AACRJQ gopalakrishnan_j_Page_071thm.jpg
7c97201bafa4938156b663266ff9dca8
ee0d26b6a568ec794bd1f063e2edf4e1fca04a56
2216 F20110109_AACSMS gopalakrishnan_j_Page_090.txt
b752fb80bc117f44f72b555f64cb201e
ff81a6b41db31a81406f97372f487e49974c9f4c
2160 F20110109_AACRKG gopalakrishnan_j_Page_112.txt
8b678f22870b2bfbb3e5e0a161c8ecb9
907ee9334725794f940571aa684649970a8ac9c7
7944 F20110109_AACSNI gopalakrishnan_j_Page_026thm.jpg
90bcde5a47dcee8eb473a9bf00d79dfb
d10466f56489e8646a610d8b8999a0fd88044d64
7519 F20110109_AACRJR gopalakrishnan_j_Page_040thm.jpg
6d3258ee0d77ce9e6cd333e29d8d27b0
9a304d73344cda92053b28adfa3d358cdeaa623a
1678 F20110109_AACSMT gopalakrishnan_j_Page_093.txt
b9557b423e1a9fdad65bb872ba301f54
8216d368910ae121eddc60fcee2766ae171ed3c5
2029 F20110109_AACRKH gopalakrishnan_j_Page_070.txt
69b18d00d50ad7428b59d8ed862cdc85
f93bae4f2ec65dd4bab3d90dde9636caafa36b7f
7175 F20110109_AACSNJ gopalakrishnan_j_Page_028thm.jpg
6b452ebfbcccc8e3bae8f2c4549c3826
5d76793e0d75469a717e2de9cc8b470b5077803a
6739 F20110109_AACRJS gopalakrishnan_j_Page_006thm.jpg
beaf8e20129db79362932fe7f782da3a
93851d48d9093893a994cd259adbb99135723d9b
1843 F20110109_AACSMU gopalakrishnan_j_Page_097.txt
961d380df10435cfa9fe44d290d10881
e17075427d8f3cc4ab61624f6acb4a2ac56d80e8
28374 F20110109_AACRKI gopalakrishnan_j_Page_012.pro
097726f38e6237a255c245d2f30a5583
c23f28a9b446d32fbf5c23aedf05a84a364ba74b
6977 F20110109_AACSNK gopalakrishnan_j_Page_031thm.jpg
0b7d5c3a6847cb1edd034e2716fa0abe
8df0d706ff11610d46328a3e97db6f1d70596d41
26432 F20110109_AACRJT gopalakrishnan_j_Page_074.QC.jpg
061e28aef157c30e0fc5aeaae6a1f976
c9efad4059bff18d21e1190a216db13c2ae9da83
1675 F20110109_AACSMV gopalakrishnan_j_Page_099.txt
88f6584458133ca7c33c9941d29f6dc2
c149695fe2f94e6f4eaf4ebd365afcf53cbeaebc
3749 F20110109_AACRKJ gopalakrishnan_j_Page_003.jpg
20f58870598c47f2efaa7a93719df52a
ad0432ef33308252202101ce96e75067a14cf988
7337 F20110109_AACSNL gopalakrishnan_j_Page_033thm.jpg
7bf04a7c20a7d8e390c91ca1084c349d
38a87a5ba877cff2751d33f1276a92bcfefd6ac3
85731 F20110109_AACRJU gopalakrishnan_j_Page_074.jpg
35573f4cef2e08be8517964ad335f05e
e2d590726b1a3586518463a16442dc4af59aebe5
F20110109_AACSMW gopalakrishnan_j_Page_104.txt
bff6247b8747b998337dc7fc3c107412
edbcbc2405ec1582f85f45d431f1b5ccb8b876bb
30061 F20110109_AACSOA gopalakrishnan_j_Page_060.QC.jpg
555b6350d15bc74411658ea28e017518
751170a173f9219367aed417c4f3b821120cdfdc
1726 F20110109_AACRJV gopalakrishnan_j_Page_109.txt
ff03289e6e7ce707e3d2da5235cf07bd
72c76042e52227f3c753a8f9c7c82b52257dc72c
452 F20110109_AACSMX gopalakrishnan_j_Page_003thm.jpg
2f81253ee7575e612403f60c053cc04d
5c3e71abf4a4da0174e9bbd89720c934a2a9586c
7692 F20110109_AACSOB gopalakrishnan_j_Page_060thm.jpg
99fae00c87178d6d02222f5f0ff22b5b
d3b46d2d3180f5336c132a18c11e3e10f9a1a8c2
5821 F20110109_AACSNM gopalakrishnan_j_Page_034thm.jpg
a2d703808610db4fae549d417918687e
0f04ecdfd5cabf97730930ba133befb27a90a11c
83139 F20110109_AACRJW gopalakrishnan_j_Page_049.jp2
92cb79324891512d2e7c49273c972f3b
a73d96d7ca8e271c6869dc08640920bb0d289782
4816 F20110109_AACSMY gopalakrishnan_j_Page_004thm.jpg
2ce41447de68f8ebd22677d50f5a1fe2
a7acc998b7adf3d26c3ca156a4426404df565ed0
79817 F20110109_AACRKK gopalakrishnan_j_Page_079.jpg
c0289d0969abad3d43703f4f91e48493
2f0e83a90a30bd33294dca871b367d7b372ff32e
8897 F20110109_AACSOC gopalakrishnan_j_Page_063thm.jpg
6ade76a1da4a077ac70408824278322d
062183a3b8ec9446a4e611f538f1d87ccc63312f
23975 F20110109_AACSNN gopalakrishnan_j_Page_035.QC.jpg
48e3213ad70b8fa16ba74fc85727c9b1
2004dd8d802e1483911077b3fafa256f1012c3e4
1514 F20110109_AACRJX gopalakrishnan_j_Page_020.txt
9f2b0adc7b20d8691d52268950d33004
0c7618a2abeef25f9c99b3766ed868b5c6ef17a5
23950 F20110109_AACSMZ gopalakrishnan_j_Page_005.QC.jpg
ee3629cb842954bb065ac016d89f0727
312698c81e69fa31779c0afc01acf70b8b014170
7650 F20110109_AACRLA gopalakrishnan_j_Page_087thm.jpg
aebf7b200675ba96fd617f648d19d2d0
a53d44aaad56c084c6645664add0ed1f3bf12490
82369 F20110109_AACRKL gopalakrishnan_j_Page_031.jpg
272a3b51c0264117174829eb58835d5c
a512a15d28528a0949c72d08ae1374a78483621d
8197 F20110109_AACSOD gopalakrishnan_j_Page_069thm.jpg
1b03f99669db36657262bbb77e52eb56
1e471996e2aed212b68e777aab6cd34994beba19
3112 F20110109_AACSNO gopalakrishnan_j_Page_036thm.jpg
e9083f106a24f722540e4b1f61b8a83d
cb8a2576b5c3b5b0e14007e8e4cc182cbdedca28
12774 F20110109_AACRJY gopalakrishnan_j_Page_008.QC.jpg
3809d99a0c2e3557478b1f4d96f2df6a
12d0c1a0468352c1fc23cce6a8bcea15b02aaa67
46917 F20110109_AACRLB gopalakrishnan_j_Page_102.pro
5be67676f21bdb88dfc4f70de45fb5e1
6012965660af0bbb5e3643c5a9b2bd2cb133aa89
24459 F20110109_AACRKM gopalakrishnan_j_Page_105.pro
e7dc79806bed9ee03fe99ca36bcc84bb
329350efb610681248caf5fcc355e705825668ba
30833 F20110109_AACSOE gopalakrishnan_j_Page_071.QC.jpg
9342a7f45b8f62c104a20a0c18584aa3
766b9fa3026c2f2af6e43844c2bac7075b2ea8be
3427 F20110109_AACSNP gopalakrishnan_j_Page_037thm.jpg
bb22f74f2c982f70c301322d2a5d488b
ead3af1a621697ef249a564b72b39ef22dc44285
920381 F20110109_AACRJZ gopalakrishnan_j_Page_093.jp2
f35d05bade0e07565fbd26ddf315aefb
099a809ce573ada4bd21e5ce97597eb7c040e153
1920249 F20110109_AACRLC gopalakrishnan_j.pdf
6e5e6609c8bd549c81d16663c2c6eb90
642daa239f1063a21cc1611ae8f5945c4e01c32e
31303 F20110109_AACRKN gopalakrishnan_j_Page_102.QC.jpg
e815bee91093041e2dc6b1328b419594
505a62775e1a25aa0866c73c36e5a12eb6ad6da0
F20110109_AACSOF gopalakrishnan_j_Page_073thm.jpg
b9eb807902e461a3e15ce56679f0368e
bb44fddbb493888730ace5407df69b19246bec6f
7267 F20110109_AACSNQ gopalakrishnan_j_Page_039thm.jpg
478425d1f3754e89060dd3b8fef8b3ba
a2a3257dd74933e241b7bce5867196f38258415e
71224 F20110109_AACRLD gopalakrishnan_j_Page_076.jp2
83a5cc086ebb336dbfe670ff58def8cd
8194b748476f0e0a90ab6cdbdca2a2de45f6a04f
26243 F20110109_AACRKO gopalakrishnan_j_Page_115.jpg
f94d1f366610e82beb0821edce2f3bfa
25652ca5ba13e765b5a055dbcf5adeef7de05eee
28526 F20110109_AACSOG gopalakrishnan_j_Page_077.QC.jpg
e90efe7931469389aa6569926188be0c
cb881a07c818bb76d1a912c214b40890168f5326
7423 F20110109_AACSNR gopalakrishnan_j_Page_044thm.jpg
57c7140354e7a1d66753898a254f64b8
8bdf3d067b337da8fa08616758f00260a1c1add9
40563 F20110109_AACRLE gopalakrishnan_j_Page_033.pro
d7fd4fc612b95342f530b5813edadeb1
5e435364c038a1ca342d804a694bd119318b2f8b
F20110109_AACRKP gopalakrishnan_j_Page_102.txt
bc326b0375890b10c465181926e2b961
28f0a65d45fc5694dd65a166b5a2523f05dae21f
30659 F20110109_AACSOH gopalakrishnan_j_Page_078.QC.jpg
50c3176c12b0540b8c735fa0430556cc
c39462aadd5cba1c14fbb203908a9449d4705d3a
7830 F20110109_AACSNS gopalakrishnan_j_Page_045thm.jpg
4b592a1b4ca8435316602402d04c25b1
3f31a144a7320bc93378b5fe518c7ef23978dd2d
80587 F20110109_AACRLF gopalakrishnan_j_Page_109.jp2
5804be13d0ebd2f32e0fe82999752bc4
217e8ea482d08296c30145f35057743b107d7843
36744 F20110109_AACRKQ gopalakrishnan_j_Page_110.pro
650a2311c61a41eb125820b113dde48a
698dcdd91609db69ef86d198dbf21c93d1ff46c3
8020 F20110109_AACSOI gopalakrishnan_j_Page_078thm.jpg
b15e096b2c6b00de4ff8773fabc856a1
29ae95fccb2c020e7dcd48e54beea0f526510480
7760 F20110109_AACSNT gopalakrishnan_j_Page_046thm.jpg
79dfc513c1d50df3213a2f59c5d13973
0abcd443a4eb21407cab0ec3776c2230f1fa6902
47464 F20110109_AACRLG gopalakrishnan_j_Page_085.pro
6415221ca9871708516661bcf0257c07
d87e4bae043b5e85ef20408f7c6de51caf767358
F20110109_AACRKR gopalakrishnan_j_Page_111.txt
41c57e0dbddfb3b714afa29f695b3ebd
820d5d335b9fa2c04c3b10aae192ac8a1c45e2da
8531 F20110109_AACSOJ gopalakrishnan_j_Page_080thm.jpg
aa5fdf437cc4e77c73738d0765fc39ad
d51d17bf3be29d5dedfc57747be40cd8aa1d419d
6590 F20110109_AACSNU gopalakrishnan_j_Page_047thm.jpg
2cac249318f60c6837823ec525f6fd95
ffabee705cd145936a34698be2e068ae9a48484e
125462 F20110109_AACRLH gopalakrishnan_j_Page_117.jpg
01d8cd196499f49798ea84f4862766ea
9890a6c82fad15284ca6cb5f90c682de7ff54f18
110857 F20110109_AACRKS gopalakrishnan_j_Page_116.jp2
2f058c5fa34aaab55a49724184892dd3
8685977858cf6f6f1eb29068300bcf7184ab11fe
27433 F20110109_AACSOK gopalakrishnan_j_Page_083.QC.jpg
bd43c24e4fa020bc85a28325c69dcb14
72bc3e8a2e0b3e91f3f6340958cb28b5d709e68c
30155 F20110109_AACSNV gopalakrishnan_j_Page_049.QC.jpg
263fce6c39b127dd375f6613faeba064
db9fe73045019af41921ee07b3aa48437ace4108
43187 F20110109_AACRLI gopalakrishnan_j_Page_041.pro
78145f659cb1b2e1f5a907ebca59e188
a81107ddd355ae7b7bbc3d1ed22823d5821251bf
8082 F20110109_AACRKT gopalakrishnan_j_Page_086thm.jpg
0408ab72f046bf2aefc7fa271ff808a2
9b186435ff7bab05626509778c3b987f5acbd831



PAGE 1

MULTIROUTING BEHAVIOR IN STREAM CONTROL TRANSMISSION PROTOCOL By JAGDISH KUMAR GOPALAKRISHNAN A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Jagdish Kumar Gopalakrishnan

PAGE 3

Dedicated to my family

PAGE 4

ACKNOWLEDGMENTS First and foremost, I would like to express my deepest reverence, gratitude and appreciation to Dr. Richard Newman, the chair of my committee. This thesis would not have been possible if it were not for his continuous direction and encouragement at each phase of this thesis. I would also like to thank Dr. Anand Rangarajan and Dr. Janise Mcnair, the members in my committee, for their detailed and circumspect appraisal of this thesis. I would also like to thank Dr. Coene Lode, Siemens, for his guidance and review of my thesis. I would also like to acknowledge the encouragement and the motivation provided to me by all my friends in CISE. Their help in giving me inputs during my research and constructive criticism has proved invaluable to me. They have also extended their support by helping me with corrections in this document. Last, but not least, I am forever indebted to my parents and sister, who have been a source of constant inspiration and support, all the way. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES.............................................................................................................ix LIST OF FIGURES.............................................................................................................x ABSTRACT ....................................................................................................................xi CHAPTER 1 INTRODUCTION TO MULTIROUTING...................................................................1 1.1 Transmission Control Protocol (TCP)....................................................................1 1.2 Stream Control Transmission Protocol (SCTP).....................................................2 1.3 Multirouting in SCTP.............................................................................................3 1.4 Roadmap Ahead......................................................................................................3 2 INTRODUCTION TO TCP AND SCTP......................................................................5 2.1 Transmission Control Protocol (TCP)....................................................................5 2.1.1 OSI and TCP/IP models...............................................................................5 2.1.2 Transport Layer............................................................................................6 2.1.3 Basics of TCP...............................................................................................6 2.1.4 TCP Connection Establishment....................................................................7 2.1.5 TCP Congestion Control..............................................................................8 2.1.5.1 Slow start and Congestion Avoidance...............................................9 2.1.5.2 Fast retransmit and Fast recovery.......................................................9 2.1.6 Different Flavors of TCP............................................................................10 2.1.6.1 Tahoe TCP........................................................................................10 2.1.6.2 Reno TCP.........................................................................................10 2.1.6.3 Vegas TCP........................................................................................11 2.1.6.4 TCP-SACK.......................................................................................11 2.1.7 TCP Connection Termination.....................................................................12 2.8 Shortcomings of TCP and the Origin of SCTP....................................................13 2.9 Features of SCTP..................................................................................................15 2.10 SCTP Association...............................................................................................16 2.11 Packet Format of SCTP......................................................................................16 2.12 SCTP Chunk Description...................................................................................17 2.13 SCTP Common Header......................................................................................18 v

PAGE 6

2.14 Various SCTP Chunk Descriptions....................................................................19 2.14.1 INIT Chunk..............................................................................................19 2.14.2 INIT ACK Chunk.....................................................................................19 2.14.3 DATA Chunk...........................................................................................19 2.14.4 SACK Chunk............................................................................................20 2.14.5 HEARTBEAT Chunk...............................................................................20 2.14.6 HEARTBEAT ACK Chunk.....................................................................20 2.14.7 ABORT Chunk.........................................................................................20 2.14.8 SHUTDOWN Chunk................................................................................20 2.14.9 SHUTDOWN ACK Chunk......................................................................21 2.14.10 SHUTDOWN COMPLETE Chunk.......................................................21 2.14.11 ERROR Chunk.......................................................................................21 2.14.12 COOKIE ECHO Chunk.........................................................................21 2.14.13 COOKIE ACK Chunk............................................................................21 2.15 SCTP Association Establishment.......................................................................21 2.16 SCTP Association Termination..........................................................................23 2.17 SCTP State Diagram...........................................................................................24 2.18 SCTP Congestion Control..................................................................................27 2.18.1 Slow Start.................................................................................................28 2.18.2 Congestion Avoidance..............................................................................28 2.19 SCTP Fault Tolerance.........................................................................................29 2.20 Security Issues in SCTP......................................................................................30 2.21 Key Points to Remember....................................................................................30 3 DESIGN OF NAVE MULTIROUTING (MROUTE)...............................................32 3.1 Motivation for Multirouting.................................................................................33 3.2 Design of Nave Multirouting or MROUTE........................................................33 3.2.1 RttUpdate().................................................................................................34 3.2.2 ProcessHeartbeatAck()...............................................................................34 3.2.3 SendBufferDequeueUpto().........................................................................35 3.3 Problem Areas of MROUTE................................................................................36 3.4 Key Points to Remember......................................................................................37 4 IMPLEMENTATION AND ISSUES OF MROUTE..................................................39 4.1 Introduction to Network Simulator (Ns-2)...........................................................39 4.1.1 Writing a TCL script for ns-2.....................................................................41 4.1.1.1 Creating the Event Scheduler...........................................................41 4.1.1.2 Creating the Network Topology.......................................................42 4.1.1.3 Creating Transport Layer Agents.....................................................42 4.1.1.4 Creating Traffic Sources..................................................................43 4.1.1.5 Tracing.............................................................................................43 4.1.1.6 Network Animator (NAM)...............................................................43 4.1.1.7 Trace Files........................................................................................44 4.1.2 Ns-2 SCTP..................................................................................................44 4.2 Simulation Setup...................................................................................................46 vi

PAGE 7

4.2.1 Configuration of the Test Bed....................................................................46 4.2.2 Metrics Used for Comparison of Results...................................................47 4.2.3 Testing Procedure.......................................................................................48 4.3 Implementation of MROUTE...............................................................................48 4.4 Comparison of MROUTE and UNMOD..............................................................49 4.5 Problem Analysis and Solutions...........................................................................53 4.5.1 Initial Cwnd................................................................................................54 4.5.1.1 Default..............................................................................................55 4.5.1.2 Using Cwnd from the Old Path........................................................55 4.5.1.3 Using History...................................................................................56 4.5.2 Retransmission...........................................................................................56 4.5.2.1 Default..............................................................................................57 4.5.2.2 Ignore GAP ACKs...........................................................................57 4.5.2.3 Preventive Retransmission...............................................................59 4.5.2.4 Receiver Stops GAP ACKs..............................................................60 4.5.3 Cwnd Growth.............................................................................................60 4.5.3.1 Default..............................................................................................61 4.5.3.2 Increase Cwnd of New Path Depending on SACKs along Old Path61 4.5.4 Oscillation...................................................................................................62 4.6 Key Points to Remember......................................................................................63 5 IMPLEMENTATION AND ISSUES OF MROUTE VARIATIONS........................64 5.1 Tabular Representation of Solutions....................................................................64 5.2 Design and Implementation of IGNORE.............................................................65 5.3 Analysis of Behavior of IGNORE........................................................................68 5.4 Design and Implementation of INC......................................................................73 5.5 Analysis and Behavior of INC..............................................................................74 5.6 Design and Implementation of CwndOLD...........................................................75 5.7 Analysis and Behavior of CwndOLD...................................................................76 5.7.1 CwndOLD1................................................................................................76 5.7.2 CwndOLD2 and CwndOLD3.....................................................................77 5.8 Comments on CwndOLD.....................................................................................78 5.9 Key Points to Remember......................................................................................79 6 RESULTS AND EVALUATION................................................................................80 6.1 Comparison of MROUTE and UNMOD..............................................................80 6.2 Comparison of MROUTE, UNMOD and IGNORE.............................................82 6.3 Comparison of MROUTE, UNMOD, IGNORE and INC....................................84 6.4 Key Points to Remember......................................................................................85 7 CONCLUSIONS AND FUTURE WORK..................................................................87 7.1 Summary...............................................................................................................87 7.2 Future Research....................................................................................................88 7.2.1 SCTP in Wireless Networks.......................................................................89 vii

PAGE 8

7.2.2 SCTP as a Transport for FTP.....................................................................90 7.2.3 SCTP as a Transport for HTTP..................................................................90 7.2.4 Achieve True Multirouting.........................................................................91 7.2.5 Complete the Matrix...................................................................................91 7.2.6 SCTP as Transport for Other Applications................................................93 APPENDIX SCTP SOURCE CODE.............................................................................94 A.1 SCTP HEADER FILE (Sctp.h)...........................................................................94 A.2 SCTP SOURCE CODE (Sctp.cc)........................................................................97 A.2.1 SetPrimary()...............................................................................................97 A.2.2 RttUpdate()................................................................................................98 A.2.3 SendBufferDequeueUpto()........................................................................99 A.2.4 ProcessHeartbeatAckChunk().................................................................102 LIST OF REFERENCES.................................................................................................104 BIOGRAPHICAL SKETCH...........................................................................................107 viii

PAGE 9

LIST OF TABLES Table page 3-1 Summary of the differences between TCP and SCTP.............................................32 4-1 Comparison of the time taken to transmit segments in UNMOD and MROUTE...53 5-1 A tabular representation of the solutions..................................................................64 5.2 Comparison of performance of UNMOD, MROUTE and IGNORE.......................71 5-3 Comparison of the timelines of UNMOD, MROUTE, IGNORE and INC.............74 6-1 Combinations of solutions for future research.........................................................92 ix

PAGE 10

LIST OF FIGURES Figure page 2-1 The 3-way handshake used for TCP connection establishment.................................8 2-2 TCP Connection termination....................................................................................13 2-3 An SCTP association and its characteristics [8].......................................................16 2-4 SCTP Packet format.................................................................................................17 2-5 SCTP Chunk format [8]...........................................................................................17 2-6 SCTP Common Header format................................................................................18 2-7 SCTP Association establishment.............................................................................22 2-8 SCTP Association termination.................................................................................24 2-9 SCTP State diagram.................................................................................................25 3-1 The calling of function RttUpdate............................................................................35 4-1 Ns-2 interaction interface between OTcl and C++...................................................41 4-2 The multihomed interface representation in Ns-2 for SCTP....................................45 4-3 The network configuration used for testing.............................................................47 4-4 A part of the timeline of the 20-second simulation of MROUTE SCTP.................50 5-1 Ambiguity in distinguishing between the SACKs for retransmission and original transmission in MROUTE........................................................................................70 6-1 Graph showing the performances of UNMOD and MROUTE................................81 6-2 Graph showing the performances of UNMOD, MROUTE and IGNORE..............83 6-3 Graph showing the performances of UNMOD, MROUTE, IGNORE and INC......84 x

PAGE 11

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science MULTIROUTING BEHAVIOR IN STREAM CONTROL TRANSMISSION PROTOCOL By Jagdish Kumar Gopalakrishnan August 2003 Chair: Richard Newman Major Department: Computer and Information Sciences Engineering The primary role of the transport layer in the ISO-OSI layered model is to provide end-to-end communications service between two or more applications running on different hosts in addition to providing flow control, congestion control and error handling. For the last two decades, end users have mainly employed either TCP or UDP of the TCP/IP suite as the transport layer for their applications. However there existed some shortcomings in TCP itself and applications wanting more functionality than what TCP or UDP could offer. As a result, SCTP (Stream Control Transmission Protocol) was spawned. SCTP is now fully embraced by IETF as a general-purpose transport protocol, joining TCP and UDP above the IP layer. Some of the added functionalities of SCTP include support for multihoming, multiple streams in an association, message boundary preservation, and protection against Denial-of-Service attacks. xi

PAGE 12

By default, the SCTP protocol supports only one active path for data transmission during the lifetime of an SCTP association. The other paths, if any, are used as standby paths for the purpose of fault tolerance in case the main primary path goes down. In this thesis, we make use of the best path in terms of the transmission time along that path and hence over-riding the idea of a single permanent primary path throughout the lifetime of an association. By measuring the RTTs (Round Trip Times) of all paths that exist in an association, the primary path can be changed to the path of least RTT. After studying the basic multirouting behavior in SCTP, we propose many design changes to the protocol to increase the data throughput. We implement many combinations of the solutions proposed, in addition to basic multirouting, to increase the rate of data transmission. Simulation tests are run in NS-2 to test all the different solutions implemented. In the end, we prove that by having the multirouting, SCTP performs better in terms of higher rate of data transmission. xii

PAGE 13

CHAPTER 1 INTRODUCTION TO MULTIROUTING In this chapter, we give brief introductions to TCP, and SCTP, and their drawbacks and advantages. This chapter also provides a general overview of the multirouting feature in SCTP, which is the crux of the thesis. In the end, a roadmap to further chapters ahead is provided. 1.1 Transmission Control Protocol (TCP) The Transport layer is one of the four layers in the TCP/IP model, which superseded the earlier ISO-OSI model. It is sandwiched between the application layer and the Internet layer. The most important role of the transport layer is to provide end-to-end communication service between two or more applications on different hosts in a network. TCP, which is a connection-oriented transport layer protocol and UDP, the connectionless transport layer protocol, have been most dominantly used in todays networks. Many new transport layer protocols had been proposed to replace TCP/UDP and overcome their shortcomings. But they have simply failed to make even a minimal impact in the domain of transport layer protocols. Some of the shortcomings of TCP have been summarized as follows: Many applications face the problem of Head-Of-Line blocking when TCP forces a strict ordering of segments to be passed to the application. It is sometimes necessary to logically distinguish between the different bytes or streams of data sent, whereas in the case of TCP, it is just a raw sequence of bytes. TCP does not support multihoming. A TCP connection is strictly defined by the communication by means of sockets between a pair of IP address and a port on one end and another pair of IP address and port on the other. TCP will not be able to 1

PAGE 14

2 use the multiple addresses that exist in a multihomed host as a part of the same TCP connection. TCP is vulnerable to Denial-Of-Service attacks, where the TCP server allocates space for the TCB (Transmission Control Block) in its kernel before the client reaffirms its genuine intention of communication with the server, by acknowledging the SYN-ACK segment sent by the server. Multiple Streams of data cannot be sent in a single TCP connection. 1.2 Stream Control Transmission Protocol (SCTP) SCTP was introduced in the October of 2000, primarily as a transport protocol in the PSTN (Public Switched Telephone Network) backbones for carrying the signaling information. SCTP also eliminated the Head-Of-Line blocking and preserved the message boundary by having different chunks for control and data. Most importantly it supported the concept of multihoming, where multiple IP addresses of a multihomed host can be used as part of a single SCTP association. SCTP also provides a solution for Denial-of-Service attacks by postponing the allocation of the memory in the stack for TCB until the client firmly commits to continuing the relationship with the server. In brief, other than fixing the defects of TCP, SCTP is very similar to TCP in other respects. SCTP follows the same congestion control features as TCP namely slow-start, congestion avoidance, fast retransmit and fast recovery. SCTP provides for the Selective Acknowledgments (SACKs) like TCP to allow for partial acknowledgments of segments received in non-sequential order. As a result of SCTPs close resemblance to TCP, the IETF (Internet Engineering Task Force) declared SCTP as a general transport layer protocol other than its use in signaling networks. The details are further elaborated in the next chapter.

PAGE 15

3 1.3 Multirouting in SCTP As stated in the RFC 2960 for SCTP [1], there is only one primary path used for data transfer in the case of a multihomed SCTP association. The other paths are used for fault tolerant purposes and become the primary path only when the current primary path goes down. Each of the paths that exist can have a different transmission characteristic such as bandwidth, delay, jitter etc., and hence we propose this multiroute feature to be added to the SCTP protocol. We have considered the delay characteristic of each path in evaluating a path and then decide whether a switch to the path of lower delay is to be made. The number of paths is dependent on the number of IP addresses exchanged during the set up of an association. The delay information of each path is collected periodically by means of the SCTP chunks sent out to check if a particular standby path is alive or not. In implementing this feature, we do not straightaway achieve the goal of higher data transmission. We encounter problems of retransmission, limited growth of the congestion window of the new path and the generation of duplicate acknowledgements with this nave approach of multiroute, which prevent us from achieving higher rate of transmission. Each of the problems is fixed individually as we finally arrive at the combination of various solutions to finally accomplish our objective of an increased rate of data transmission, as compared to the unmodified SCTP. 1.4 Roadmap Ahead We start the formal discussion in the second chapter, where the basics of TCP, the congestion control algorithms of TCP and the different flavors of TCP are explained.

PAGE 16

4 SCTP is introduced later in the chapter along with its different chunk formats and it concludes with the connection establishment and termination. In the third chapter, we elaborate on the design of the nave multiroute feature. The various design issues and problems encountered in the basic implementation of multiroute are explained. We also arrive at a matrix representation of the combinations of the different categories of solutions. In the fourth and fifth chapters, the implementation details of the three solutions that we proposed to incorporate efficient multirouting in the SCTP protocol are dealt with. We progressively analyze the behavior of SCTP for each of the implementations, by using a particular network scenario in Ns-2 (Network Simulator). Results are then graphically compared with the results obtained with the results of unmodified SCTP in terms of the number of segments transmitted in unit time (20 seconds). In the sixth chapter, the simulation results are restated and evaluated against the metric, which is the number of data segments transmitted in unit time, i.e., bytes per second. We find that by embedding the efficient multirouting in the SCTP stack as we have done, we are able to ultimately achieve a higher rate of data transmission. We conclude in the seventh chapter by summarizing all the activities carried out and the results obtained in this thesis. In an orientation towards future research, a few interesting ideas and projects that can be done in the area of SCTP are listed.

PAGE 17

CHAPTER 2 INTRODUCTION TO TCP AND SCTP This chapter explains the basics of TCP, its different flavors and goes on to discuss the congestion control algorithms in TCP. It also gives an introduction to SCTP, the different chunk formats in SCTP, the establishment of an SCTP association and concludes with the differences between TCP and SCTP. 2.1 Transmission Control Protocol (TCP) 2.1.1 OSI and TCP/IP models The ISO (International Standards Organization) is responsible for the genesis of the seven-layered layered model ISO-OSI (Open Systems Interconnect) to define the functionalities of the different layers of the network operating system. Each of the seven layers namely the Application layer, Presentation layer, Session layer, Transport Layer, Network layer, Data link layer and the Physical layer, was defined with clearly defined interfaces and input/output for interaction between the different layers. In what was started as a defense research project for the Department of Defense (DOD), the TCP/IP model was commercially introduced shortly after. It superseded the OSI model and is most widely used today. TCP/IP model does not exactly match with the OSI model. All the functionalities of the seven layers of the OSI model were reduced to four layers in the TCP/IP model namely Application layer, Transport layer, Internet Layer and the Network Access layer. 5

PAGE 18

6 2.1.2 Transport Layer The Transport Layers primary role includes providing end-to-end communications between two or more applications running on different hosts. The other functionalities of the transport layer is summarized as follows [1]: Manage the flow control of data between peers across the network. Provide error checking to guarantee error-free delivery of data. Guarantees a reliable data transfer by providing acknowledgements (ACKs) for data chunks received. Retransmission of lost segments. Follows efficient congestion control algorithms to stabilize the flow of data in case of congestion in the network. There are two transport layer protocols in the TCP/IP model. One is the reliable connection oriented Transmission Control Protocol (TCP) and the other is the connectionless User Datagram Protocol (UDP). UDP does not perform any end-to-end reliability checks. Our focus in the thesis as a whole is on the transport layer. 2.1.3 Basics of TCP As mentioned earlier, TCP is a reliable connection oriented protocol and based on point-to-point communication between two network hosts. Before a peer can start sending data through a TCP connection, a TCP session has to be established between the two hosts. The host initiating the TCP association (client) and the receiving host (server) are said to perform the active open and the passive open respectively. The server waits on a well-known port to provide a particular service, which enables clients to connect to it. Some well known TCP ports used by standard TCP-based programs are 20 (FTP data channel), 21 (FTP control channel), 23 (Telnet), 53 (Domain Name System), 80 (Webserver-HTTP) etc.

PAGE 19

7 Richard Stevens defines a connection to be the communication link between two processes, i.e., a client and a server [2]. An association is used to define a 5-tuple that completely specifies the two processes that make up a connection: { protocol, local-addr, local-process, foreign-addr, foreign-process } The protocol we use here is TCP. The local-addr is the IP address of the network interface used by the client for data transmission. Local-process is a local port used to identify the application that is to receive the data received on this connection. Foreign-addr is the IP address of the network interface of the peer or the server, which the client communicates with. Foreign-process is nothing but the well-known ports. 2.1.4 TCP Connection Establishment Establishment of a TCP connection involves the creation of sockets at both ends of the connection. A socket is defined as the one end-point of a two-way communication link between two programs running on the network. Socket APIs (Application Program Interfaces) provide an application interface to the communication protocols. Socket APIs such as socket, accept, bind, connect, listen, send, recv etc. are used for the setting up of the connection and the transmission of data along a connection. The TCP session is established by means of a 3-way handshake where the client initiates an active open and sends a TCP-SYN segment to the server. The TCP-SYN segment contains the clients initial sequence number. The server, on passive open, accepts the TCP-SYN segment and acknowledges it by sending a SYN-ACK segment. The SYN-ACK segment also contains the initial sequence number of the server. The client on receiving the SYN-ACK acknowledges it by sending an ACK to the server. This is the 3-way handshake protocol used for establishment of a TCP connection and is depicted in the diagram below.

PAGE 20

8 Figure 2-1: The 3-way handshake used for TCP connection establishment 2.1.5 TCP Congestion Control A retransmission timer is started at the sender side when a segment is transmitted. This expires if the segment is not ACKed within a certain time duration depending on the RTT of the path. The expiry of the retransmission timer indicates a lost segment and the segment is immediately retransmitted before any new data segments are transmitted. In the next section, we look at four algorithms, namely, slow start, congestion avoidance, fast retransmit and fast recovery [2,3]. Before moving on to the TCP congestion control algorithms, we need to look at a few variables maintained in the TCP stack for following the rules of congestion. Cwnd: This is the congestion window variable maintained in bytes by either ends of the connection. This value is used to control the flow of data from the sender side. The sender, at any time can transmit up to the minimum of the congestion window and the advertised receiver window (rwnd). Rwnd: This is the value in bytes advertised by the receiver as to the no of bytes of space available in the receiver buffer for the sender to fill up. In other words, rwnd

PAGE 21

9 is nothing but the flow control imposed by the receiver. As mentioned before, a sender can only transmit up to the minimum of the value of cwnd and rwnd. Ssthresh: This is the slow start threshold. Slow start is discussed in the next section. When the value of cwnd is less than or equal to ssthresh, then slow start algorithm is followed or else congestion avoidance algorithm is followed. 2.1.5.1 Slow start and Congestion Avoidance Initially the values of cwnd and ssthresh are set to 1 or 2 times SMSS (Sender Maximum Segment Size) bytes and 65,535 bytes respectively. This is because when the connection is started, TCP does not know the conditions of the network and hence it starts to experiment slowly by setting cwnd to 1 or 2 SMSS bytes. During the period of slow start, i.e., as long as cwnd is less than or equal to ssthresh, for each ACK received that acknowledges new data, TCP increases the value of cwnd by at most SMSS bytes When the value of cwnd is greater than ssthresh, the congestion avoidance phase kicks in. In congestion avoidance, the value of cwnd is incremented by 1 full sized segment per RTT (Round Trip time). Congestion avoidance is continued till the congestion is detected. A commonly used formula used to affect the value of cwnd during congestion avoidance is as follows: cwnd += SMSS SMSS / cwnd When congestion occurs (indicated by a timeout or the receipt of duplicate ACKs, values of cwnd and ssthresh are affected as described in the next section. 2.1.5.2 Fast retransmit and Fast recovery Fast Retransmit and Fast Recovery algorithms are usually implemented together as indicated by the following steps: 1. A TCP receiver has to immediately notify the other end if there are any gaps in the segment numbers that it receives. So it generates a duplicate ACK whenever an out-of-order segment is received. If the sender receives three such duplicate ACKS, it is definitely a strong indication that a segment is lost. 2. When the sender receives three duplicate ACKs, then it retransmits the missing segment without waiting for the retransmission timer to expire. This is the fast retransmit algorithm. Now the value of ssthresh is set to the maximum of the values of (FlightSize / 2) and 2 SMSS. ssthresh = max (FlightSize/2, 2 SMSS).

PAGE 22

10 FlightSize is nothing but the number of outstanding bytes maintained at the sender end, which have not yet been acknowledged by the receiver. The new value of the cwnd is set to ssthresh plus 3 times the segment size. 3. Additionally if the congestion is indicated by a timeout, then slow start algorithm is again followed. 4. Each time another duplicate ACK is received, increment cwnd by SMSS and transmit the packet if allowed by the new value of cwnd. 5. When the next ACK acknowledging the new data arrives, set the value of cwnd to ssthresh (which is the same value set in step 1). This ACK should also acknowledge all the segments sent between the lost packet and the receipt of the third duplicate ACK. 2.1.6 Different Flavors of TCP Since TCP was originally introduced, it has undergone a lot of modifications to yield better performance. In this section we briefly look at a few flavors of TCP in the recent years. 2.1.6.1 Tahoe TCP The base version of TCP did very little to combat congestion and used the go-back-N model to go back N segments and retransmit all the data lost following the expiration of the retransmit timer. The congestion algorithms such as the slow start, congestion avoidance and fast retransmit algorithms discussed in the previous section were added to the base version of TCP resulting in Tahoe TCP. It also included the modification to the round-trip time estimator to set the retransmission timeout values. This led to better bandwidth utilization and throughput than the base version. 2.1.6.2 Reno TCP Reno TCP contained all the modifications incorporated into Tahoe TCP, but also included the fast recovery algorithm discussed in the previous section. At the receipt of three duplicate ACKs, the Tahoe sender used to go into slow-start after retransmitting the

PAGE 23

11 missing segment. But Reno TCP decreases the congestion window by one half and uses incoming ACKs to increment the congestion window. Since the receiver can only generate the duplicate ACK when another segment is received, that segment has left the network and is in the receivers buffer. This means that there is still data flow going on between the sender and the receiver, and this should not abruptly be reduced by following the slow start. Hence the value of cwnd is set to a higher value as described in the slow start section. Reno TCP shows a better and optimized performance than Tahoe TCP when a single packet is dropped from a window of data. But the performance can be affected when multiple packets are dropped from a window of data. 2.1.6.3 Vegas TCP Vegas TCP showed a further 40% 70% improvement in the throughput as compared to the Reno implementation of TCP [4]. A new retransmission policy is used in Vegas. In Reno, the arrival of three duplicate ACKs trigger the process of retransmission, but Vegas uses a time stamp for each packet sent to calculate the RTT on each ACK received. If the difference between the timestamp for that packet and the current time is greater than the timeout value, then Vegas TCP retransmits the packet without waiting for the third duplicate ACK from the receiver. If there are any losses of ACKs since the retransmission, then the segments are retransmitted without the wait for duplicate ACKs. A comparison of the actual throughput and the expected throughput to the threshold values is made and then the window size is decreased or increased linearly. 2.1.6.4 TCP-SACK SACK stands for Selective ACKs [5]. Initially the base implementation of TCP used the cumulative acknowledgement scheme, in which the non-contiguous segments

PAGE 24

12 received after the highest numbered segment in sequential order, were not acknowledged. This made the sender to either wait for one RTT to detect each lost packet or retransmit the segments even though they have reached the receiver albeit in non-sequential order. Thus the TCP-SACK option was introduced which could inform the sender about the highest numbered segment received in order and the non-contiguous segments received. Since this is an extension to the base TCP, some TCP versions may support it whereas many may not. Hence it becomes essential at the time of the connection establishment to decide whether both ends would follow the SACK option or not. To indicate the non-contiguous segments received, the 40 bytes of TCP options in the TCP header is made use of. A start block and an end block represent each block of contiguous data in the set of non-contiguous data. The start block indicates the starting sequence number and the end block represents the ending sequence number. Sally Floyd has performed simulation-based comparisons of Tahoe, Reno and SACK TCP [6]. 2.1.7 TCP Connection Termination Since a TCP connection is full duplex, it needs to be shut down independently from both ends. To close a connection, a FIN segment is sent across to the other end. The receiver of FIN segment sends an ACK of the FIN segment. The end that issues the close first performs the active close and the other end performs the passive close. After one end does the active close, the other end does the passive close. When the FIN segment is received, there will not be any more data flow from the sender of the FIN segment. After an end sends across the FIN segment, it can still receive the data from the other end. This is known as the half close connection when the peer that has sent the FIN segment and received the ACK for the FIN, is waiting for the FIN segment from the other peer.

PAGE 25

13 The connection termination is shown in figure 2-2. Figure 2-2: TCP Connection termination. 2.8 Shortcomings of TCP and the Origin of SCTP For the last two decades, the TCP/IP suite (which is slightly different from the OSI suite) has dominated the networking world. Either TCP (Transmission Control Protocol) or the UDP (User Datagram Protocol) has been used widely used in applications worldwide as a transport layer protocol. Some applications using TCP, however, needed additional features than what TCP currently offered. There were a few vulnerable factors about using TCP, which we will describe shortly. Ivan quotes the following deficiencies in TCP [7]: Many applications such as the streaming video do not require the strict ordering of segments before passing them on to the application. This produces Head-Of-Line (HOL) blocking. In this case TCP would produce the unnecessary delay in strict ordering. Therefore a transport layer protocol, apart from providing the connection oriented features also needed to have an option of unreliable and non-strict or partial order delivery of segments to the application.

PAGE 26

14 TCP treats data transmission as an unstructured sequence of bytes. Streams cannot be logically demarcated and it is up to the application to insert their marks inside the streams explicitly. TCP does not support the concept of multihoming. Multihoming is the ability of a host to support multiple IP addresses. It is not possible to associate more than one IP address of a host to one end as a part of the same TCP connection. Thus a host with multiple interface cards will not be able to use all its IP addresses as a part of the same TCP connection. The reason for using the multiple IP addresses as a part of an association could be for the reasons of load sharing or fault tolerance. We will discuss these issues in the coming sections. TCP is vulnerable to Denial-Of-Service (DOS) attacks or SYN attacks. This happens during the three-way handshake of the TCP connection initialization. The entity, which does the passive open of the TCP connection, always allocates resources for an impending TCP connection after it receives a SYN segment and responds with a SYN-ACK. The application that does the active open may not respond with the ACK and may not complete the three-way handshake. This activity, when repeated, may exhaust the kernel resources to start a fresh TCP connection and ultimately it becomes impossible to spawn TCP connections. TCP does not allow applications to have control over the TCP timers like the initialization timers, retransmission timers etc. One of the main applications, which found these above features of TCP lacking, was the transport of PSTN (Public Switched Telephone Network) signaling across an IP network. Thus, to overcome all these deficiencies of TCP, MDTP (Multi-Network Datagram Transmission Protocol) was introduced by Randall Stewart and Qiaobing Xie. Later on, they modified this to introduce SCTP. SCTP was initially called Signaling Common Transport Protocol. But later, it was realized that SCTP could be used as an alternate for TCP for normal networking applications other than signaling transport. The reasons being that it behaved in a similar manner as TCP in addition to overcoming the above mentioned limitations. So it was renamed to Stream Control Transmission Protocol.

PAGE 27

15 SCTP is a very recent transport protocol dating back to October 2000 when Randall Stewart et al introduced the RFC 2960 [8], which formally describes SCTP. 2.9 Features of SCTP We describe below, the features of SCTP in contrast to deficiencies of TCP and the general features offered: Head-Of-Line (HOL) blocking is eliminated by SCTP as it also provides an option for both sequenced delivery of segments and unordered delivery of segments to the application. It supports both TCP and UDP modes of delivery. Having separation between logically structured sequences of bytes called chunks, preserves message boundary. Thus control information and the actual data can be grouped into separate chunks. SCTP provides support for multihoming. During the phase of establishment of an SCTP association, either side can include one or more IP addresses as a part of the association. A feature to include the IP addresses dynamically in the middle of an association is also being provided currently [9]. However as we will discuss later, only one path between a pair of IP addresses is allowed to be the primary path for communication between two end points. Using the feature of multihoming, the probability of the data chunks that have been transmitted, reaching their destinations will be increased [10]. SCTP supports multiple streams of data in a single association. To create the independence in data transmission and data delivery, two sets of sequence numbers are used: a unique Transmission Sequence Number (TSN) for each data chunk and a unique Stream Sequence Number (SSN) to identify a data chunk within a particular stream [10]. SCTP prevents the Denial-Of-Service attacks by using a 4-way handshake it uses while starting a new association. We will describe the 4-way handshake in the later sections of this chapter. Basically SCTP does not allocate any resources when it receives an INIT (the equivalent of a TCP SYN) from a client. Instead it forms a cookie that embeds all the information required for forming a connection (information required to form a Transmission Control Block) and sends it across to the client. Only when the client echoes back the cookie to the server, will the actual allocation of resources take place at the server end. SCTP follows TCPfriendly congestion control algorithms. This includes the slow-start, congestion avoidance and retransmission algorithms of TCP. SCTP also derives the Selective Acknowledgement (SACK) derived from TCP. It provides a GAP ACK block that includes information about non-contiguous segments that are missing at the receiver end.

PAGE 28

16 SCTP has a Heartbeat chunk which are sent periodically along the different paths of an association. By this mechanism it decides whether a particular endpoint or interface of the other end has failed. This feature is currently used in SCTP as a fault tolerance mechanism. User data is fragmented to fit the Maximum Transmission Unit (MTU) along a particular route. A mandatory Verification tag field and a 32 bit check sum (Addler checksum) is added to the SCTP header for validation after an endpoint receives a packet. Any application running over TCP can be ported to run over SCTP. 2.10 SCTP Association The diagram below shows an overview of an SCTP association aggregating all the features of SCTP that have been described above [8]. Figure 2-3. An SCTP association and its characteristics [8] 2.11 Packet Format of SCTP Since SCTP can logically distinguish between the different chunks, the generic format of an SCTP packet would be the common SCTP Header followed by its chunks.

PAGE 29

17 Figure 2-4: SCTP Packet format 2.12 SCTP Chunk Description Each SCTP chunk is specific to its functionality. The Chunk has information about the Chunk Type, different flags for that chunk, length of the chunk and the value of the chunk (data). The general format of an SCTP chunk is shown below: Figure 2-5: SCTP Chunk format [8] Chunk Type: This field is an 8-bit unsigned integer. There can be various chunk types like INIT, DATA, INIT-ACK etc. A short description of some of the relevant chunks is described in the next section. Chunk Flags: This is of 8 bits. This contains information pertaining to a particular chunk. Chunk Length: This is a 16-bit unsigned integer and contains the length of the chunk in bytes. This field does not include the length of the padding. Chunk Value: This is a variable length field containing the actual data to be transmitted. The type of data it carries is dependent on the type of the chunk.

PAGE 30

18 2.13 SCTP Common Header SCTP Header is similar to the TCP Header with information such as the source port number, destination port number, and check sum. It also contains the verification tag for validation purposes. Fields such as Acknowledgement number, sequence number etc. found in the TCP header are not found in the SCTP Header. Since there is message preservation in SCTP and the existence of chunks, the individual chunks carry this information. Figure 2-6 shows the SCTP Header. Figure 2-6: SCTP Common Header format Source Port Number: This is a 16 bit unsigned integer. It contains the port number of the SCTP sender. Destination Port Number: This is a 16 bit unsigned integer. It contains the port number of the SCTP destination. Verification Tag: This is a 32 bit unsigned integer. This is used to check if the packet is coming from a valid and right host. It contains the value that was agreed upon while sending the INIT and INIT-ACK chunks during the initialization of the SCTP association. Checksum: This is a 32 bit unsigned integer containing the checksum of the SCTP Packet.

PAGE 31

19 2.14 Various SCTP Chunk Descriptions Depending on the value of the chunk type, we have various chunks that are described in this section. 2.14.1 INIT Chunk This chunk is analogous to the TCP SYN segment sent during the initialization of the segment. This contains an initiate tag, used as a verification tag in all other segments sent by the receiver of the INIT. The use of the verification tag has already been discussed earlier. The number of inbound and outbound streams in the association is also negotiated during the sending of this chunk. The INIT chunk also contains the receiver window size that is advertised along with one or more IP addresses that would be used during the association to support multihoming. The Initial Sequence Number (ISN) is also a part of the INIT chunk. 2.14.2 INIT ACK Chunk This chunk is sent in response to an INIT chunk. The format of this chunk is similar to the INIT chunk except that it also contains the State Cookie, which is generated by the sender of the INIT ACK chunk. As described earlier, this is a method to prevent the Denial-Of-Service attacks. 2.14.3 DATA Chunk This carries the user data along with the information such as the TSN (Transmission Sequence Number), Stream Sequence number (since multiple streams can be transmitted as a part of a single association) etc. The fields just described are analogous to the Sequence number in TCP, except that they have been moved to the chunks from the header portion.

PAGE 32

20 2.14.4 SACK Chunk This is the Selective Acknowledgement Chunk. As the name indicates, this chunk is used to acknowledge data where the Transmission Sequence Number (TSN) of the data received may or may not be in a sequence. To indicate non sequential data received, this chunk has a GAP ACK block, which has a GAP ACK start number and a GAP ACK end number indicating the TSNs of the chunks received. This chunk also has a duplicate TSN block to let the sender know of any duplicate chunks received. It also carries the Cumulative TSN ACK, which contains the TSN of the last DATA chunk received in sequence before a gap. 2.14.5 HEARTBEAT Chunk HEARTBEAT chunks are usually sent to detect the reachability of a destination. This normally includes the information about the senders current time when the HEARTBEAT is sent. 2.14.6 HEARTBEAT ACK Chunk HEARTBEAT ACK chunks are sent in response to HEARTBEAT chunks. It is always sent to the source IP address of the datagram containing the HEARTBEAT chunk. 2.14.7 ABORT Chunk ABORT chunks are sent to shut down an association abruptly. It also contains the error code as to why the association was terminated. DATA chunks must not be bundled with the ABORT chunk. 2.14.8 SHUTDOWN Chunk SHUTDOWN is sent to facilitate a graceful shutdown of an SCTP association. It also contains the Cumulative TSN Ack, which is the TSN of the last chunk received in sequence before any gaps.

PAGE 33

21 2.14.9 SHUTDOWN ACK Chunk SHUTDOWN ACK is sent in response to a SHUTDOWN chunk. 2.14.10 SHUTDOWN COMPLETE Chunk SHUTDOWN COMPLETE is used to acknowledge the receipt of the SHUTDOWN ACK chunk. This is sent at the end of the shutdown process. 2.14.11 ERROR Chunk ERROR chunk is sent to indicate to its peer end point of an error condition. There can be various error conditions such as Unresolvable Address, Unrecognized parameters, Out of Resource etc. 2.14.12 COOKIE ECHO Chunk This chunk is used in the initialization of an association. The peer end wanting to initiate an association sends this chunk. This completes the initialization process from the client side. This chunk must be sent before any DATA chunks can be transmitted. 2.14.13 COOKIE ACK Chunk COOKIE ACK chunk is sent in response to a COOKIE ECHO chunk. Again, before any DATA chunks can be transmitted, this chunk should be transmitted. 2.15 SCTP Association Establishment SCTP has a 4-way handshake unlike TCPs 3-way handshake in establishing an association. The following are the steps involved in the 4-way handshake: One of the ends sends an INIT chunk with all the necessary information embedded in it. The sender of INIT now starts a timer, T1-init timer and enters the COOKIE-WAIT state. The receiver of the INIT chunk responds by sending an INIT ACK chunk. The verification tag in the INIT and INIT ACK chunks is used for validation purposes during future transmissions of data. The receiver now generates a cookie and

PAGE 34

22 embeds in it, all the information needed to establish a TCB (Transmission Control Block) and sends it along with the INIT ACK. No resources are allocated at the receiver end for the TCB. When the sender of INIT receives the cookie from the peer end, it stops the T1-init timer and sends the cookie back in a COOKIE ECHO chunk. After this it starts the T1-cookie timer and enters the COOKIE-ECHOED state. The data transmission can actually start with this chunk. After receiving the COOKIE ECHO chunk, the peer establishes the TCB and changes to the ESTABLISHED state. It now sends a COOKIE ACK, which could also be bundled along with other data chunks. When the other end receives the COOKIE ACK chunk, it now moves to the ESTABLISHED state and stops the T1-cookie timer. The diagram below shows the SCTP association establishment. The steps described above can also be seen in the SCTP State diagram in the next section. Figure 2-7: SCTP Association establishment.

PAGE 35

23 2.16 SCTP Association Termination SCTP uses a 3-way handshake when the association has to be terminated unlike TCPs four exchanges for complete termination of the connection. The steps for a normal and a graceful shutdown are described as follows: The application issues a SHUTDOWN primitive to the SCTP asking it to shut down the association. Since there is no concept of half closed states like in TCP, all the data has to be flushed out before sending the SHUTDOWN chunk. It now reaches the SHUTDOWN-PENDING state before the data is sent. After all the pending data is sent, a SHUTDOWN chunk is sent and moves to the SHUTDOWN-SENT state. It also starts the T2-shutdown timer. When the other end receives the SHUTDOWN chunk, it goes to SHUTDOWN-RECEIVED state. Now it is this ends turn to send all the outstanding data to the other end. Also the SHUTDOWN receiver must not receive any fresh DATA chunks from the other end during this time. The SHUTDOWN sender now restarts the T2-shutdown timer each time it receives fresh DATA chunks and responds with a SACK. But the SHUTDOWN sender must not send data at this point of time. The SHUTDOWN receiver now sends a SHUTDOWN ACK chunk and moves to SHUTDOWN-ACK-SENT state. When the SHUTDOWN sender receives the SHUTDOWN ACK, it stops the T2-shutdown timer and sends a SHUTDOWN COMPLETE chunk to its peer and thus erases all traces of this association. Thus the association at this point of time is completely broken down. The diagram 2-6 shows the steps in the SCTP termination. These states are also shown in the SCTP state diagram later in the chapter.

PAGE 36

24 Figure 2-8: SCTP Association termination 2.17 SCTP State Diagram The next two pages describe the SCTP State diagram, including the different states that have already been discussed during the association initialization and termination.

PAGE 37

25 Figure 2-9: SCTP State diagram

PAGE 38

26 Figure 2-9: continued

PAGE 39

27 2.18 SCTP Congestion Control SCTP congestion control algorithms are very similar to the TCP congestion control. It follows the slow start algorithm, congestion avoidance, fast retransmission and recovery just like TCP. The one main difference between the TCP and SCTP congestion control is that since SCTP supports multihoming, it is necessary to store and maintain the congestion control parameters for all paths of a multihomed association. SCTP provides for SACKs and GAP ACKs to indicate selective acknowledgement and gaps in the received segments. SCTP maintains three congestion control parameters: Congestion Control window (cwnd): This is maintained in bytes. This indicates a limit of how many bytes the sender can currently send to the peer end, provided the flight size and the receiver window permit it. Its function is similar to ssthresh in TCP. Slow Start threshold (ssthresh): This is stored in bytes and is used to distinguish between slow start and congestion avoidance. Its function is similar to ssthresh in TCP. Receiver Window size (rwnd): This is the limit set by the receiver as to how many bytes it can receive contingent on the buffer size and how much the application has emptied the receiver buffer. It is again emphasized that there are separate variables stored for each of the destination addresses. But only one rwnd variable is kept. Apart from these variables, another variable partial_bytes_acked records the number of bytes that have been partially ACKed by GAP ACKs and otherwise. Slow start and congestion avoidance is similar to those of TCP except that partial_bytes_acked also comes into the picture as described in the steps below.

PAGE 40

28 2.18.1 Slow Start Slow start algorithm is used to probe a network initially before injecting data into it because one is not aware of the conditions of the network initially. The initial cwnd is set to 2 MTU (Maximum Transmission Unit) bytes at the start. After a retransmission, the cwnd is set to 1 MTU. The initial value of ssthresh is set to a high value like 65536. When the cwnd is less than or equal to ssthresh, then slow start algorithm is to be used. If an incoming SACK advances the Cumulative TSN ACK point (which is nothing but the highest TSN received in sequence so far), then cwnd must be increased by a minimum of either the total size of the DATA chunks acknowledged OR the destination paths MTU. When an endpoint does not transport data on a given address, the cwnd of that path must be set to the maximum of (cwnd /2) OR 2 MTU per RTO (Retransmission Time Out). 2.18.2 Congestion Avoidance Congestion Avoidance is to be used when the value of the ssthresh is less than cwnd. Initially partially_bytes_acked is set to zero. When cwnd is greater than ssthresh, each SACK that arrives increases partially_bytes_acked by the number of bytes acknowledged. When the sender has cwnd or more bytes of data outstanding and partial_bytes_acked is greater than or equal to cwnd, then increase cwnd by MTU bytes and reset partial_bytes_acked to (partial_bytes_acked cwnd). Obviously when all the data has been acknowledged, partial_bytes_acked is reset to zero. Whenever data segments are indicated as missing by way of the SACKs or GAP ACKs, i.e., whenever the number of missing segment reports reaches four, then it follows fast retransmission. Here the value of ssthresh is reduced to a maximum of (cwnd / 2) and 2 MTU. The value of cwnd is now set equal to ssthresh, However if the retransmission timer waiting on the ACKs expires, SCTP performs slow start

PAGE 41

29 by setting cwnd to 1 MTU and ssthresh to a maximum of (cwnd / 2) and 2 MTU. 2.19 SCTP Fault Tolerance Like TCP, SCTP makes use of HEARTBEAT chunks to find out if a particular destination is still alive or not. This is analogous to the keep-alive timer in TCP. The following steps describe the operation of the heartbeat mechanism in SCTP: During the setting up of an association, the periodic interval at which HEARTBEAT chunks are sent to a destination is provided. After the heartbeat timer expires, the host sends HEARTBEAT chunks with the timing information in it. If the HEARTBEAT chunk is not acknowledged with a HEARTBEAT ACK within the RTO, then an error counter for that destination is incremented. When the error counter of a destination path reaches an upper bound, Path.Max.Retrans, then that path is declared inactive. But when the HEARTBEAT ACK is received from the destination, then the error counter is cleared. The receiver of the HEARTBEAT chunk copies the information from it onto a HEARTBEAT ACK chunk. The application can set the interval HB.interval, i.e., the interval at which HEARTBEAT chunks are to be sent out to a destination. Since the HEARTBEAT chunk contains the timing information as to when that particular chunk was sent, the RTT (Round Trip Time) of that path can be calculated and updated. The SCTP HEARTBEAT chunks are similar to the TCP Keep-alive timer. The option to enable the TCP keep-alive timer is provided by the setsocket() API of the socket API. TCP sends a keep-alive packet periodically to check if the particular endpoint is alive or not.

PAGE 42

30 2.20 Security Issues in SCTP SCTP mainly uses the verification tag and the cookie as security mechanisms in addition to using the IpSec features of the network layer [11, 12]. SCTP as a protocol does not define any new security protocols or procedures [10]. 2.21 Key Points to Remember In this chapter, we have discussed the basics of TCP, its different flavors, the congestion control algorithms in TCP. We also discussed SCTP, its different chunks and establishment and termination of an SCTP association.. We also summarized the differences between TCP and SCTP. In a TCP connection, there exists only a single path of communication between two endpoints because a TCP connection is strictly between an IP address and a port on one end and an IP address and a port on the other end. It does not support the concept of multihoming. Therefore the issue of multipath routing does not arise at all in TCP, as it does not support multihoming. But in SCTP, since it supports the concept of multihoming, there exists multiple paths as a part of a single association. Thus we should be able to use the different paths provided as a part of the association after evaluating each one of them. In this manner, we are able to realize the true utilization of all the paths as opposed to using a single path during the duration of an association. The HEARTBEAT chunks that we described have a significant bearing on the topic of this thesis. As we see in the next chapter, it is the HEARTBEAT chunks using which we decide whether to switch over to a new path and make it the primary communication path. We make use of the timing information and calculate the RTT, in

PAGE 43

31 order to switch over to a path that has the least RTT. We will discuss more about this in the next chapter.

PAGE 44

CHAPTER 3 DESIGN OF NAVE MULTIROUTING (MROUTE) This chapter discusses the motivation for introducing the multirouting feature in the SCTP protocol. It also explains the problems we faced with a nave multirouting feature, which we called MROUTE. The categories of problems that we face in MROUTE and the solutions that we propose are presented in the form of a matrix. The various design issues and decisions that were made are also elaborated. Table 3-1: Summary of the differences between TCP and SCTP. TCP SCTP Head-of-line blocking due to the strict ordering of segments produces unnecessary delay in certain applications. Head-of-line blocking is eliminated as SCTP supports both the options of both strict and non-strict ordering of segments. It supports both a TCP mode and a UDP mode of transmission. Data transmission is treated as an unstructured sequence of bytes with no differentiation between streams. Separation exists between logically structured sequences of bytes known as chunks. Multihoming support is not provided. Multihoming support is provided with the ability to dynamically add/remove IP addresses in the middle of an SCTP association. Vulnerable to Denial-of-Service attacks. Due to the cookie mechanism during the initialization of the association, Denial-of-Service attacks can be avoided. Application control over the TCP timers does not exist. Application control over SCTP timers is possible Keep-alive timers are used to detect if a destination is alive or not. HEARTBEAT chunks are used to detect if a destination is alive or not. No scope for multipath routing as the support for multihoming is not provided. Multipath routing is possible making use of the property of multihoming. If the path of communication goes down, there is no fault tolerance provided, as there are no standby paths. Through the support for multihoming, fault tolerance is provided by means of the other paths functioning as standby paths. 32

PAGE 45

33 In the previous chapter, we talked about TCP, SCTP and the differences between them. The above table briefly summarizes the differences between TCP and SCTP. 3.1 Motivation for Multirouting According to the SCTP RFC [8], there is only one active path where the primary communication of data takes place during a SCTP association. If the association is multihomed, the other paths exist just as standby paths. If the primary path goes down due to some reason, a standby path is made the primary path. The choosing of the primary path currently does not depend on any criterion. By default the path connecting the source IP addresses of the datagram containing the INIT and the INIT ACK chunks is chosen as the primary path for communication. The other IP addresses, which exist as a part of a multihomed association, are specified in the INIT and INIT ACK chunks. The other paths are never evaluated and come into play only for the purpose of fault tolerance. The network conditions such as failures and congestion change dynamically all the time. Hence we argue that using just one primary path for communication does not utilize the multihoming feature of SCTP completely. As a result, we propose that the other paths should be evaluated and used, when they become better than the primary path currently used for transmission. Now the question of how a particular path is chosen over other paths comes into consideration. 3.2 Design of Nave Multirouting or MROUTE We mentioned that the HEARTBEAT chunks are sent out periodically to detect whether a particular destination is alive or not. We also recall that HEARTBEAT chunks contain timing information and this is used to update the RTT (Round Trip Time) estimators.

PAGE 46

34 Round Trip Time is one of the critical factors influencing the throughput of data transfer. If there are two paths of different RTTs, then the path with the lower RTT will ultimately yield a higher rate of data transmission than the path with the higher RTT. The RTTs of the various paths are updated when the HEARTBEAT ACK chunks arrive along them. The RTT of the primary path is known since there is a regular flow of DATA chunks along it. Thus the information about the RTTs of all the paths is available at any point of time. Hence whenever RTT of a particular path is updated we compare the RTTs of all the paths and then decide whether primary path needs to be changed based on the comparison. Whenever the primary path is changed to another path, then the data transfer takes place along the new path chosen till another path of lesser RTT is available. We now look at the various functions in the SCTP source code that are used when the multirouting feature is introduced. 3.2.1 RttUpdate() RttUpdate is a function that updates the RTT of a path, which it takes in as a parameter. The function prototype is as follows: void SctpAgent::RttUpdate(double dTxTime, SctpDest_S *spDest) dTxTime is the time stamp information. SpDest is the destination, whose RTT needs to be updated based on dTxTime and the current time. 3.2.2 ProcessHeartbeatAck() ProcessHeartbeatAck, as the name suggests, is the function that is called whenever a HEARTBEAT ACK is received in response to a HEARTBEAT chunk. In short, this function clears the error counter associated with a specific destination and based on the time stamp received, updates the RTT of the path. Error counter keeps track

PAGE 47

35 of the number of times that the HEARTBEAT ACK was not received, before it declares the other end as dead. The prototype of the function is as follows: void SctpAgent::ProcessHeartbeatAckChunk( SctpHeartbeatAckChunk_S *spHeartbeatAckChunk) SpHeartbeatAckChunk is the structure containing the HEARTBEAT ACK chunk. 3.2.3 SendBufferDequeueUpto() When DATA chunks are transmitted, they are stored in the SendBuffer till the other end acknowledges them. Whenever a SACK is received, then this function is called to dequeue the DATA chunks from the SendBuffer. Only those DATA chunks that have been acknowledged will be dequeued from the SendBuffer. After they are dequeued, the RTT information is updated and the timer is stopped if the destination timer was still running. Thus we can see that there are two instances where the RTT information needs to be updated. Both the ProcessHeartbeatAck() and SendBufferDequeueUpto() functions need to call RttUpdate() as shown in the following diagram. Figure 3-1: The calling of function RttUpdate

PAGE 48

36 After the RTT information is updated in the function RttUpdate, we compare the RTTs of all the paths. The multiple IP addresses of the peer end may be set up during the association set up or by dynamically adding the IP address in the middle of an association [9]. We then change the primary path of communication to the new path if it is found to be of lesser RTT. Otherwise we continue transmission along the old path. We call this the nave multiroute or MROUTE since we do not make any other modifications to the code and expect it to prove beneficial in terms of the rate of data transmission. Logically speaking, the change of path to that of a lesser RTT should improve the performance with respect to the throughput or increased rate of data transmission. 3.3 Problem Areas of MROUTE We discuss the implementation details of MROUTE and other solutions in the next chapter. Before going on to the next chapter, the problems that we faced with the nave multirouting feature are listed. The problems associated with MROUTE can be categorized into 4 classes: 1. Initial Cwnd Problem: The initial value of the cwnd of the new path determines how many segments we transmit initially. Different solutions to start the cwnd of the new path with a higher value are discussed. One of the solutions that we discuss in this category is the hysteresis method, where history of collected data pairs of (cwnd, RTT) would help in choosing an appropriate path. 2. Retransmission problem: As we will see in the analysis of our results in the next chapter, retransmission of segments takes place due to segments on the new path reaching the destination before earlier transmitted segments. Retransmission consumes considerable time and network resources. Alternatives to prevent this behavior are discussed. Here we discuss the solutions of ignoring GAP ACKs (IGNORE) and preventive retransmission in addition to the default, unmodified behavior of SCTP. 3. Cwnd growth: After we follow one of the solutions that we list for the Initial Cwnd problem, the growth of cwnd from that point on affects the rate of data

PAGE 49

37 transmission. We look at the different alternatives that can be followed for the cwnd growth. In this category, we address solutions like increasing the cwnd of the new path based on the old path. 4. Oscillation: Basically this problem arises due to the occurrence of too many path changes in a given time and may bring about instability in the system. The Hysteresis method handles this problem to some extent. The research on this topic is not carried out in this thesis and is reserved for future work. 3.4 Key Points to Remember Solutions to the first three categories of problems are listed in table 3-1. We address each of these solutions and discuss the pros and cons of each one of them in the next chapter. Table 3-2: A tabular representation of the solutions. Initial Cwnd Retransmission Method Path Change (Y / N) Default (1) Hysteresis Value Old-path Default Preventive Retransmission Ignore GAP ACKs UNMOD N MROUTE Y IGNORE Y INC Y CwndOLD Y Or Cwnd Growth Method Path Change (Y / N) Default Use SACKs to increase cwnd UNMOD MROUTE IGNORE Y INC Y CwndOLD Y Or Default solutions in each of the categories shown above indicate the current, unmodified default behavior of the SCTP protocol, which we call UNMOD. We have named the different combinations of the solutions that we have tried out as UNMOD,

PAGE 50

38 MROUTE, IGNORE and INC. As indicated in the table, the cross symbol () shows the combination of solutions that we tried out for each of the methods that we mention.

PAGE 51

CHAPTER 4 IMPLEMENTATION AND ISSUES OF MROUTE We discussed the design of nave multirouting or MROUTE in the previous chapter. We also addressed the problem areas in this design and came up with a tabular representation of the different alternatives along with a brief introduction to each of the problems. Before we elaborate on the details of the solutions, we give an introduction to Network Simulator (Ns-2) using which we carry out the simulations. This chapter is concluded with a detailed network scenario description and comparison of the behavior of MROUTE and UNMOD. 4.1 Introduction to Network Simulator (Ns-2) Network Simulator, Ns-2, is an open source discreet event simulator tool targeted at network research and provides substantial support for simulation of routing, multicast protocols and IP protocols, such as TCP, UDP, SCTP, RTP over wired and wireless (local and satellite) networks [13,14]. Ns-2 was developed by Information Sciences Institute (ISI) at the University of Southern California (USC). Tcl, pronounced tickle, stands for Tool Command Language and its associated user interface is called Tk, which stands for toolkit. Tcl/Tk is one of the widely used scripting languages used these days. Tcl is a simple programming language. Tcl scripts are basically made of Tcl commands, separated by newlines and colons. The reasons for choosing to use Tcl in ns-2 over any other programming language such as C, is that Tcl provides a much simpler interface to the functionality and syntax. This does not require the knowledge of any high-level programming language, compilers or linkers. 39

PAGE 52

40 OTcl is an extension to the basic Tcl shell that provides the object-oriented features. OTcl is a superset of Tcl, and has the same relationship as C to C++. Correspondence is required between classes at the C++ level and their corresponding OTcl classes. TclCl is responsible for providing the link. In summary, Ns-2 requires the following packages to run: Tcl release 8.3.2, Tk release 8.3.2, OTcl release 1.0a7 and TclCl release 1.0b11 Ns-2 is written in and C++ and Otcl. The use of OTcl enables the networking components to be defined as OTcl classes. Simulation scripts are programmed in OTcl scripting language. Apart from simulating the network protocols, the traffic source behavior (e.g., Variable Bit Rate (VBR), Constant Bit Rate (CBR)), router queue management mechanisms, routing algorithms, multicasting protocols, MAC layer protocols, etc., can also be simulated by the Ns-2 tcl scripts. For the reasons of scalability, extensibility and efficiency, Ns-2 uses a split-language approach, using two languages, C++ and OTcl as a part of its architecture. The control path implementation is separate from the data path implementation. C++ code runs fast, making it ideal for protocol implementations. And OTcl can be modified quickly, thus making it suitable to write the Tcl scripts. Hence, if there is a need to process a packet or change the implementation of an existing protocol stack, C++ is used. OTcl is used as an interface to interact with the protocol code through the Tcl scripts written for simulation, configuration set-up, etc.

PAGE 53

41 Figure 4-1: Ns-2 interaction interface between OTcl and C++. As we can see, a Tcl script written for simulation interacts with the Otcl layer, which internally creates a correspondence to the C++ object through the OTcl linkage. The event scheduler and the basic network components of the data path are implemented and compiled in C++ and are made available to the outside world through their corresponding OTcl objects through the OTcl linkage. Thus the control methods and the class variables of the C++ object now become accessible through the member functions and variables respectively of the OTcl object. 4.1.1 Writing a TCL script for ns-2 4.1.1.1 Creating the Event Scheduler An event scheduler tracks the simulation time and triggers the various events scheduled to occur at particular time intervals. It fires the events in the event queue at particular times by invoking various network components and execute the appropriate action as specified. An event scheduler is created by the command: set ns [new Simulator] An event is scheduled by the command: $set at
Permanent Link: http://ufdc.ufl.edu/UFE0001189/00001

Material Information

Title: Multitrouting behavior in stream control transmission protocol
Physical Description: Mixed Material
Creator: Gopalakrishnan, Jagdish Kumar ( Author, Primary )
Publication Date: 2003
Copyright Date: 2003

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001189:00001

Permanent Link: http://ufdc.ufl.edu/UFE0001189/00001

Material Information

Title: Multitrouting behavior in stream control transmission protocol
Physical Description: Mixed Material
Creator: Gopalakrishnan, Jagdish Kumar ( Author, Primary )
Publication Date: 2003
Copyright Date: 2003

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0001189:00001


This item has the following downloads:


Full Text












MULTIROUTING BEHAVIOR IN STREAM CONTROL TRANSMISSION
PROTOCOL












By

JAGDISH KUMAR GOPALAKRISHNAN


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003

































Copyright 2003

by

Jagdish Kumar Gopalakrishnan

































Dedicated to my family















ACKNOWLEDGMENTS

First and foremost, I would like to express my deepest reverence, gratitude and

appreciation to Dr. Richard Newman, the chair of my committee. This thesis would not

have been possible if it were not for his continuous direction and encouragement at each

phase of this thesis. I would also like to thank Dr. Anand Rangarajan and Dr. Janise

Mcnair, the members in my committee, for their detailed and circumspect appraisal of

this thesis. I would also like to thank Dr. Coene Lode, Siemens, for his guidance and

review of my thesis.

I would also like to acknowledge the encouragement and the motivation provided

to me by all my friends in CISE. Their help in giving me inputs during my research and

constructive criticism has proved invaluable to me. They have also extended their support

by helping me with corrections in this document.

Last, but not least, I am forever indebted to my parents and sister, who have been a

source of constant inspiration and support, all the way.
















TABLE OF CONTENTS
page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TABLES ............................................. ..... .. ..... ....... ....... ix

LIST OF FIGURES ............................... ... ...... ... ................. .x

A B S T R A C T .................................................................................. x i

CHAPTER

1 INTRODUCTION TO MULTIROUTING...................................... ................. ......

1.1 Transmission Control Protocol (TCP) ............................... .............1
1.2 Stream Control Transmission Protocol (SCTP) ............................................. 2
1.3 M ultirouting in SC TP ......................... .......................... .. ......... ............ .....
1.4 R oadm ap A h ead ............. ... ....................................................................... .. .. ....

2 INTRODUCTION TO TCP AND SCTP ........................................... ............... 5

2.1 Transmission Control Protocol (TCP) .....................................................5
2.1.1 O SI and T C P/IP m odels ........................................ ............................... 5
2.1.2 Transport L ayer ..................... .. ....................... .. ...... ................ .6
2.1.3 B asics of T C P ..................................................................
2.1.4 TCP Connection Establishment........................... ....................7
2.1.5 TCP Congestion Control ........................................... ......... .........8
2.1.5.1 Slow start and Congestion Avoidance ............................................9
2.1.5.2 Fast retransm it and Fast recovery ...................................................9
2.1.6 D different Flavors of TCP............................................................ .......... 10
2 .1.6 .1 T ahoe T C P ............................. .............. .................. .... ....... .. 10
2.1.6.2 R eno T C P ... ........... ..... .... ........ ............................................. 10
2.1.6.3 V egas TCP ............................................... .... .. ................. 11
2.1.6.4 TCP-SA CK .................. .............................. .. .. .. ................. 11
2.1.7 TCP Connection Termination......................... ......................... 12
2.8 Shortcomings of TCP and the Origin of SCTP ............................................. 13
2.9 Features of SCTP .................. ..................................... ............ 15
2.10 SCTP Association .................. .......................... .... .... ................. 16
2.11 Packet Form at of SC TP ............................................... ............ ............... 16
2.12 SCTP Chunk D description ............................................................................17
2.13 SC T P C om m on H eader ......................................................................... ...... 18


v









2.14 V various SCTP Chunk D descriptions ........................................ .....................19
2 .14 .1 IN IT C hunk ..................... .. .......................... ........ .... ...........19
2 .14 .2 IN IT A C K C hunk ......................................................................... ... ... 19
2.14.3 D A TA C hunk ............................................. ... ........ .. ............ ..... 19
2 .14 .4 SA C K C hunk ............. .................................................... .. .... ..... .. 20
2.14.5 H EAR TBEA T Chunk......................................... .......................... 20
2.14.6 HEARTBEAT ACK Chunk .......................................... ............... 20
2.14.7 A BORT Chunk .................................................................... 20
2.14.8 SH U TD O W N C hunk.................................................................. ........ 20
2.14.9 SHUTDOWN ACK Chunk ............. ............................................ 21
2.14.10 SHUTDOWN COMPLETE Chunk ................................................. 21
2 .14 .11 E R R O R C hu nk ............................................................ .....................2 1
2.14.12 COOK IE ECH O Chunk ........................................ ...... ............... 21
2.14.13 COOKIE ACK Chunk ................................................................ 21
2.15 SCTP A association Establishm ent ............................................ ............... 21
2.16 SCTP A association Term nation .............................................. ............... 23
2 .17 SC T P State D iagram ..................................................................................24
2.18 SCTP Congestion Control ............................................................................ 27
2 .1 8 .1 S lo w S ta rt ........................................................................................... 2 8
2.18.2 C ongestion A voidance......................................... .......... ............... 28
2 .19 SC T P F ault T olerance.............................................................. .....................29
2.20 Security Issues in SC TP ........................................................... ............... 30
2.2 1 K ey P points to R em em ber........................................................................ .. .... 30

3 DESIGN OF NAIVE MULTIROUTING (MROUTE)................. ..................32

3.1 Motivation for Multirouting ................................................... 33
3.2 Design of Naive Multirouting or MROUTE ................................ ...............33
3 .2 .1 R ttU pdateo ................................................................................ 34
3.2.2 ProcessH eartbeatA ck ) ..... ............ ..................................... .........34
3.2.3 SendBufferD equeueU pto .................................. .................................... 35
3.3 Problem A reas of M R O U TE .................................................................... ...... 36
3.4 K ey P points to R em em ber ......................................................................... ... ... 37

4 IMPLEMENTATION AND ISSUES OF MROUTE............... .................39

4.1 Introduction to Network Simulator (Ns-2) ................................. ...............39
4.1.1 W writing a TCL script for ns-2.................................................................. 41
4.1.1.1 Creating the Event Scheduler............................... ............... 41
4.1.1.2 Creating the N network Topology.....................................................42
4.1.1.3 Creating Transport Layer Agents................. ............................42
4.1.1.4 Creating Traffic Sources ...................................... ............... 43
4 .1.1.5 T racing ............................................ ........... .. ......... 43
4.1.1.6 Network Animator (NAM)...........................................................43
4 .1.1.7 T race F iles ........................................................... ............... 44
4.1.2 N s-2 SCTP .................. .......... ......................... ...... 44
4.2 Sim ulation Setup ........................................46............................









4.2.1 Configuration of the Test Bed ....................................... ...............46
4.2.2 M etrics Used for Comparison of Results ................................................47
4.2.3 Testing Procedure ......................... ............................... .............. 48
4.3 Implementation of MROUTE............................................ 48
4.4 Comparison of MROUTE and UNMOD...........................................................49
4.5 Problem Analysis and Solutions................................ ......................... ....... 53
4.5.1 Initial Cw nd ................ ..................... .......... ..... .... .. ........ .... 54
4 .5 .1 .1 D efau lt ......................... .. ......... ...... ... ...... ................ 5 5
4.5.1.2 Using Cwnd from the Old Path................................... ............... 55
4.5.1.3 U sing H history ....................................... ........ ........ ......56
4 .5.2 R etransm mission ..................... .. ...................... .. .. ...... ........... 56
4.5.2.1 Default ............................ ...............57
4.5.2.2 Ignore G A P A CK s ........................................ ........ ............... 57
4.5.2.3 Preventive Retransm mission .................................... ............... 59
4.5.2.4 Receiver Stops GAP ACK s................................... ............... 60
4 .5.3 C w nd G row th ........................ .. ....................... .... .. ........... 60
4 .5 .3 .1 D e fau lt .................................. ..... ..................................... 6 1
4.5.3.2 Increase Cwnd of New Path Depending on SACKs along Old Path61
4 .5 .4 O sc illatio n ............................................................................................. 6 2
4.6 K ey Points to R em em ber...................... .... ................................. ............... 63

5 IMPLEMENTATION AND ISSUES OF MROUTE VARIATIONS ......................64

5.1 Tabular R presentation of Solutions ........................................ .....................64
5.2 Design and Implementation of IGNORE ........................ ................... 65
5.3 Analysis of Behavior of IGNORE................... ............................. ............... 68
5.4 Design and Implementation of INC................................................................... 73
5.5 Analysis and Behavior of INC ............................ ..................... .......... 74
5.6 Design and Implementation of CwndOLD....................................................75
5.7 Analysis and Behavior of CwndOLD .............. ............................................76
5.7.1 C w ndO L D 1 ............................................. ...... .. .............. .. ............ 76
5.7.2 CwndOLD2 and CwndOLD3 .......................................... ............... 77
5.8 Comments on CwndOLD .................................. .....................................78
5.9 K ey Points to R em em ber ................................................... ... ............79

6 RESULTS AN D EVALU A TION .................................................................. ........80

6.1 Comparison of M ROUTE and UNM OD ................................... .....................80
6.2 Comparison of MROUTE, UNMOD and IGNORE..........................................82
6.3 Comparison of MROUTE, UNMOD, IGNORE and INC ...................................84
6.4 K ey P points to R em em ber ........................................................... ..................... 85

7 CONCLUSIONS AND FUTURE WORK .............. .............................................87

7 .1 S u m m a ry ......................................................................................................... 8 7
7.2 Future Research ............................ ....................... ........88
7.2.1 SCTP in W wireless N etworks.................................................................... 89









7.2.2 SCTP as a Transport for FTP .......................................... ............... 90
7.2.3 SCTP as a Transport for H TTP ...................................... ............... 90
7.2.4 Achieve True Multirouting.......................... ..........................91
7.2.5 Complete the Matrix ......... ........ ......... ....... ........... 91
7.2.6 SCTP as Transport for Other Applications .............................................93

APPENDIX SCTP SOURCE CODE ........................................ ........................ 94

A 1 SCTP H EA D ER FILE (Sctp.h) ................................................ .....................94
A.2 SCTP SOURCE CODE (Sctp.cc).................................................................97
A .2. 1 SetPrim ary().............................................. .. ...... .. ............ 97
A .2 .2 R ttU p d ate ................................ .... ...................................... ........ .... 9 8
A.2.3 SendBufferDequeueUpto) ................................................ ...................99
A.2.4 ProcessHeartbeatAckChunk ...................................... ............... 102

LIST OF REFEREN CES ........................................................... .. ............... 104

BIOGRAPHICAL SKETCH ............................................................. ............... 107



































viii
















LIST OF TABLES


Table pge

3-1 Summary of the differences between TCP and SCTP. .........................................32

4-1 Comparison of the time taken to transmit segments in UNMOD and MROUTE. ..53

5-1 A tabular representation of the solutions .............................................. ................64

5.2 Comparison of performance of UNMOD, MROUTE and IGNORE.....................71

5-3 Comparison of the timelines of UNMOD, MROUTE, IGNORE and INC. ............74

6-1 Combinations of solutions for future research .......... .... ............. ..................... 92
















LIST OF FIGURES


Figure pge

2-1 The 3-way handshake used for TCP connection establishment.............................8

2-2 TCP Connection term ination.............................................................................. .... 13

2-3 An SCTP association and its characteristics [8]..................... ............................... 16

2-4 SCTP Packet form at ........................................................... .. ............... 17

2-5 SC T P C hunk form at [8] ............................................ ......................................... 17

2-6 SCTP Com m on H eader form at .................................................................... ...... 18

2-7 SCTP Association establish ent. ........................................ ....................... 22

2-8 SCTP A association term nation .......................................................... ............... 24

2-9 SCTP State diagram ................................................ ...............25

3-1 The calling of function RttUpdate............ ....... ................ ................. 35

4-1 Ns-2 interaction interface between OTcl and C++.......................................... 41

4-2 The multihomed interface representation in Ns-2 for SCTP...................................45

4-3 The netw ork configuration used for testing ........................................ ..................47

4-4 A part of the timeline of the 20-second simulation of MROUTE SCTP. ................50

5-1 Ambiguity in distinguishing between the SACKs for retransmission and original
transm mission in M R O U TE .............................................. .............................. 70

6-1 Graph showing the performances of UNMOD and MROUTE............................. 81

6-2 Graph showing the performances of UNMOD, MROUTE and IGNORE. ............83

6-3 Graph showing the performances of UNMOD, MROUTE, IGNORE and INC......84















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

MULTIROUTING BEHAVIOR IN STREAM CONTROL TRANSMISSION
PROTOCOL

By

Jagdish Kumar Gopalakrishnan

August 2003

Chair: Richard Newman
Major Department: Computer and Information Sciences Engineering



The primary role of the transport layer in the ISO-OSI layered model is to provide

end-to-end communications service between two or more applications running on

different hosts in addition to providing flow control, congestion control and error

handling. For the last two decades, end users have mainly employed either TCP or UDP

of the TCP/IP suite as the transport layer for their applications. However there existed

some shortcomings in TCP itself and applications wanting more functionality than what

TCP or UDP could offer. As a result, SCTP (Stream Control Transmission Protocol) was

spawned. SCTP is now fully embraced by IETF as a general-purpose transport protocol,

joining TCP and UDP above the IP layer. Some of the added functionalities of SCTP

include support for multihoming, multiple streams in an association, message boundary

preservation, and protection against Denial-of-Service attacks.









By default, the SCTP protocol supports only one active path for data transmission

during the lifetime of an SCTP association. The other paths, if any, are used as standby

paths for the purpose of fault tolerance in case the main primary path goes down. In this

thesis, we make use of the best path in terms of the transmission time along that path and

hence over-riding the idea of a single permanent primary path throughout the lifetime of

an association. By measuring the RTTs (Round Trip Times) of all paths that exist in an

association, the primary path can be changed to the path of least RTT. After studying the

basic multirouting behavior in SCTP, we propose many design changes to the protocol to

increase the data throughput. We implement many combinations of the solutions

proposed, in addition to basic multirouting, to increase the rate of data transmission.

Simulation tests are run in NS-2 to test all the different solutions implemented. In

the end, we prove that by having the multirouting, SCTP performs better in terms of

higher rate of data transmission.














CHAPTER 1
INTRODUCTION TO MULTIROUTING

In this chapter, we give brief introductions to TCP, and SCTP, and their

drawbacks and advantages. This chapter also provides a general overview of the

multirouting feature in SCTP, which is the crux of the thesis. In the end, a roadmap to

further chapters ahead is provided.

1.1 Transmission Control Protocol (TCP)

The Transport layer is one of the four layers in the TCP/IP model, which

superseded the earlier ISO-OSI model. It is sandwiched between the application layer and

the Internet layer. The most important role of the transport layer is to provide end-to-end

communication service between two or more applications on different hosts in a network.

TCP, which is a connection-oriented transport layer protocol and UDP, the

connectionless transport layer protocol, have been most dominantly used in today's

networks. Many new transport layer protocols had been proposed to replace TCP/UDP

and overcome their shortcomings. But they have simply failed to make even a minimal

impact in the domain of transport layer protocols.

Some of the shortcomings of TCP have been summarized as follows:

* Many applications face the problem of Head-Of-Line blocking when TCP forces a
strict ordering of segments to be passed to the application.

* It is sometimes necessary to logically distinguish between the different bytes or
streams of data sent, whereas in the case of TCP, it is just a raw sequence of bytes.

* TCP does not support multihoming. A TCP connection is strictly defined by the
communication by means of sockets between a pair of IP address and a port on one
end and another pair of IP address and port on the other. TCP will not be able to









use the multiple addresses that exist in a multihomed host as a part of the same
TCP connection.

* TCP is vulnerable to Denial-Of-Service attacks, where the TCP server allocates
space for the TCB (Transmission Control Block) in it's kernel before the client
reaffirms its genuine intention of communication with the server, by
acknowledging the SYN-ACK segment sent by the server.

* Multiple Streams of data cannot be sent in a single TCP connection.

1.2 Stream Control Transmission Protocol (SCTP)

SCTP was introduced in the October of 2000, primarily as a transport protocol in

the PSTN (Public Switched Telephone Network) backbones for carrying the signaling

information. SCTP also eliminated the Head-Of-Line blocking and preserved the

message boundary by having different chunks for control and data. Most importantly it

supported the concept of multihoming, where multiple IP addresses of a multihomed host

can be used as part of a single SCTP association. SCTP also provides a solution for

Denial-of-Service attacks by postponing the allocation of the memory in the stack for

TCB until the client firmly commits to continuing the relationship with the server.

In brief, other than fixing the defects of TCP, SCTP is very similar to TCP in

other respects. SCTP follows the same congestion control features as TCP namely slow-

start, congestion avoidance, fast retransmit and fast recovery. SCTP provides for the

Selective Acknowledgments (SACKs) like TCP to allow for partial acknowledgments of

segments received in non-sequential order. As a result of SCTP's close resemblance to

TCP, the IETF (Internet Engineering Task Force) declared SCTP as a general transport

layer protocol other than its use in signaling networks. The details are further elaborated

in the next chapter.









1.3 Multirouting in SCTP

As stated in the RFC 2960 for SCTP [1], there is only one primary path used for

data transfer in the case of a multihomed SCTP association. The other paths are used for

fault tolerant purposes and become the primary path only when the current primary path

goes down. Each of the paths that exist can have a different transmission characteristic

such as bandwidth, delay, jitter etc., and hence we propose this multiroute feature to be

added to the SCTP protocol. We have considered the delay characteristic of each path in

evaluating a path and then decide whether a switch to the path of lower delay is to be

made.

The number of paths is dependent on the number of IP addresses exchanged

during the set up of an association. The delay information of each path is collected

periodically by means of the SCTP chunks sent out to check if a particular standby path is

alive or not. In implementing this feature, we do not straightaway achieve the goal of

higher data transmission. We encounter problems of retransmission, limited growth of the

congestion window of the new path and the generation of duplicate acknowledgements

with this naive approach of multiroute, which prevent us from achieving higher rate of

transmission.

Each of the problems is fixed individually as we finally arrive at the combination

of various solutions to finally accomplish our objective of an increased rate of data

transmission, as compared to the unmodified SCTP.

1.4 Roadmap Ahead

We start the formal discussion in the second chapter, where the basics of TCP, the

congestion control algorithms of TCP and the different flavors of TCP are explained.









SCTP is introduced later in the chapter along with its different chunk formats and it

concludes with the connection establishment and termination.

In the third chapter, we elaborate on the design of the naive multiroute feature.

The various design issues and problems encountered in the basic implementation of

multiroute are explained. We also arrive at a matrix representation of the combinations of

the different categories of solutions.

In the fourth and fifth chapters, the implementation details of the three solutions

that we proposed to incorporate efficient multirouting in the SCTP protocol are dealt

with. We progressively analyze the behavior of SCTP for each of the implementations,

by using a particular network scenario in Ns-2 (Network Simulator). Results are then

graphically compared with the results obtained with the results of unmodified SCTP in

terms of the number of segments transmitted in unit time (20 seconds).

In the sixth chapter, the simulation results are restated and evaluated against the

metric, which is the number of data segments transmitted in unit time, i.e., bytes per

second. We find that by embedding the efficient multirouting in the SCTP stack as we

have done, we are able to ultimately achieve a higher rate of data transmission.

We conclude in the seventh chapter by summarizing all the activities carried out

and the results obtained in this thesis. In an orientation towards future research, a few

interesting ideas and projects that can be done in the area of SCTP are listed.














CHAPTER 2
INTRODUCTION TO TCP AND SCTP

This chapter explains the basics of TCP, its different flavors and goes on to discuss the

congestion control algorithms in TCP. It also gives an introduction to SCTP, the different

chunk formats in SCTP, the establishment of an SCTP association and concludes with the

differences between TCP and SCTP.

2.1 Transmission Control Protocol (TCP)

2.1.1 OSI and TCP/IP models

The ISO (International Standards Organization) is responsible for the genesis of

the seven-layered layered model ISO-OSI (Open Systems Interconnect) to define the

functionalities of the different layers of the network operating system. Each of the seven

layers namely the Application layer, Presentation layer, Session layer, Transport Layer,

Network layer, Data link layer and the Physical layer, was defined with clearly defined

interfaces and input/output for interaction between the different layers.

In what was started as a defense research project for the Department of Defense

(DOD), the TCP/IP model was commercially introduced shortly after. It superseded the

OSI model and is most widely used today. TCP/IP model does not exactly match with the

OSI model. All the functionalities of the seven layers of the OSI model were reduced to

four layers in the TCP/IP model namely Application layer, Transport layer, Internet

Layer and the Network Access layer.









2.1.2 Transport Layer

The Transport Layer's primary role includes providing end-to-end communications

between two or more applications running on different hosts. The other functionalities of

the transport layer is summarized as follows [1]:

* Manage the flow control of data between peers across the network.

* Provide error checking to guarantee error-free delivery of data.

* Guarantees a reliable data transfer by providing acknowledgements (ACKs) for
data chunks received.

* Retransmission of lost segments.

* Follows efficient congestion control algorithms to stabilize the flow of data in case
of congestion in the network.

There are two transport layer protocols in the TCP/IP model. One is the reliable

connection oriented Transmission Control Protocol (TCP) and the other is the

connectionless User Datagram Protocol (UDP). UDP does not perform any end-to-end

reliability checks. Our focus in the thesis as a whole is on the transport layer.

2.1.3 Basics of TCP

As mentioned earlier, TCP is a reliable connection oriented protocol and based on point-

to-point communication between two network hosts. Before a peer can start sending data

through a TCP connection, a TCP session has to be established between the two hosts.

The host initiating the TCP association (client) and the receiving host (server) are said to

perform the active open and the passive open respectively. The server waits on a well-

known port to provide a particular service, which enables clients to connect to it. Some

well known TCP ports used by standard TCP-based programs are 20 (FTP data channel),

21 (FTP control channel), 23 (Telnet), 53 (Domain Name System), 80 (Webserver-

HTTP) etc.









Richard Stevens defines a connection to be the communication link between two

processes, i.e., a client and a server [2]. An association is used to define a 5-tuple that

completely specifies the two processes that make up a connection:

{ protocol, local-addr, local-process, foreign-addr, foreign-process }

The protocol we use here is TCP. The local-addr is the IP address of the network

interface used by the client for data transmission. Local-process is a local port used to

identify the application that is to receive the data received on this connection. Foreign-

addr is the IP address of the network interface of the peer or the server, which the client

communicates with. Foreign-process is nothing but the well-known ports.

2.1.4 TCP Connection Establishment

Establishment of a TCP connection involves the creation of sockets at both ends

of the connection. A socket is defined as the one end-point of a two-way communication

link between two programs running on the network. Socket APIs (Application Program

Interfaces) provide an application interface to the communication protocols. Socket APIs

such as socket, accept, bind, connect, listen, send, recv etc. are used for the setting up of

the connection and the transmission of data along a connection.

The TCP session is established by means of a 3-way handshake where the client

initiates an active open and sends a TCP-SYN segment to the server. The TCP-SYN

segment contains the client's initial sequence number. The server, on passive open,

accepts the TCP-SYN segment and acknowledges it by sending a SYN-ACK segment.

The SYN-ACK segment also contains the initial sequence number of the server. The

client on receiving the SYN-ACK acknowledges it by sending an ACK to the server. This

is the 3-way handshake protocol used for establishment of a TCP connection and is

depicted in the diagram below.










Client Server











ACK

DATA






Figure 2-1: The 3-way handshake used for TCP connection establishment

2.1.5 TCP Congestion Control

A retransmission timer is started at the sender side when a segment is transmitted.

This expires if the segment is not ACKed within a certain time duration depending on the

RTT of the path. The expiry of the retransmission timer indicates a lost segment and the

segment is immediately retransmitted before any new data segments are transmitted.

In the next section, we look at four algorithms, namely, slow start, congestion

avoidance, fast retransmit and fast recovery [2,3]. Before moving on to the TCP

congestion control algorithms, we need to look at a few variables maintained in the TCP

stack for following the rules of congestion.

* Cwnd: This is the congestion window variable maintained in bytes by either ends
of the connection. This value is used to control the flow of data from the sender
side. The sender, at any time can transmit up to the minimum of the congestion
window and the advertised receiver window (rwnd).

* Rwnd: This is the value in bytes advertised by the receiver as to the no of bytes of
space available in the receiver buffer for the sender to fill up. In other words, rwnd









is nothing but the flow control imposed by the receiver. As mentioned before, a
sender can only transmit up to the minimum of the value of cwnd and rwnd.

* Ssthresh: This is the slow start threshold. Slow start is discussed in the next section.
When the value of cwnd is less than or equal to ssthresh, then slow start algorithm
is followed or else congestion avoidance algorithm is followed.

2.1.5.1 Slow start and Congestion Avoidance

* Initially the values of cwnd and ssthresh are set to 1 or 2 times SMSS (Sender
Maximum Segment Size) bytes and 65,535 bytes respectively. This is because
when the connection is started, TCP does not know the conditions of the network
and hence it starts to experiment slowly by setting cwnd to 1 or 2 SMSS bytes.

* During the period of slow start, i.e., as long as cwnd is less than or equal to
ssthresh, for each ACK received that acknowledges new data, TCP increases the
value of cwnd by at most SMSS bytes

* When the value of cwnd is greater than ssthresh, the congestion avoidance phase
kicks in. In congestion avoidance, the value of cwnd is incremented by 1 full sized
segment per RTT (Round Trip time). Congestion avoidance is continued till the
congestion is detected. A commonly used formula used to affect the value of cwnd
during congestion avoidance is as follows:

cwnd += SMSS SMSS / cwnd

* When congestion occurs (indicated by a timeout or the receipt of duplicate ACKs,
values of cwnd and ssthresh are affected as described in the next section.

2.1.5.2 Fast retransmit and Fast recovery

Fast Retransmit and Fast Recovery algorithms are usually implemented together as

indicated by the following steps:

1. A TCP receiver has to immediately notify the other end if there are any gaps in the
segment numbers that it receives. So it generates a duplicate ACK whenever an
out-of-order segment is received. If the sender receives three such duplicate ACKS,
it is definitely a strong indication that a segment is lost.

2. When the sender receives three duplicate ACKs, then it retransmits the missing
segment without waiting for the retransmission timer to expire. This is the fast
retransmit algorithm. Now the value of ssthresh is set to the maximum of the values
of (FlightSize / 2) and 2 SMSS.


ssthresh = max (FlightSize/2, 2 SMSS).









FlightSize is nothing but the number of outstanding bytes maintained at the sender
end, which have not yet been acknowledged by the receiver.

The new value of the cwnd is set to ssthresh plus 3 times the segment size.

3. Additionally if the congestion is indicated by a timeout, then slow start algorithm is
again followed.

4. Each time another duplicate ACK is received, increment cwnd by SMSS and
transmit the packet if allowed by the new value of cwnd.

5. When the next ACK acknowledging the new data arrives, set the value of cwnd to
ssthresh (which is the same value set in step 1). This ACK should also
acknowledge all the segments sent between the lost packet and the receipt of the
third duplicate ACK.

2.1.6 Different Flavors of TCP

Since TCP was originally introduced, it has undergone a lot of modifications to

yield better performance. In this section we briefly look at a few flavors of TCP in the

recent years.

2.1.6.1 Tahoe TCP

The base version of TCP did very little to combat congestion and used the go-

back-N model to go back N segments and retransmit all the data lost following the

expiration of the retransmit timer. The congestion algorithms such as the slow start,

congestion avoidance and fast retransmit algorithms discussed in the previous section

were added to the base version of TCP resulting in Tahoe TCP. It also included the

modification to the round-trip time estimator to set the retransmission timeout values.

This led to better bandwidth utilization and throughput than the base version.

2.1.6.2 Reno TCP

Reno TCP contained all the modifications incorporated into Tahoe TCP, but also

included the fast recovery algorithm discussed in the previous section. At the receipt of

three duplicate ACKs, the Tahoe sender used to go into slow-start after retransmitting the









missing segment. But Reno TCP decreases the congestion window by one half and uses

incoming ACKs to increment the congestion window. Since the receiver can only

generate the duplicate ACK when another segment is received, that segment has left the

network and is in the receiver's buffer. This means that there is still data flow going on

between the sender and the receiver, and this should not abruptly be reduced by following

the slow start. Hence the value of cwnd is set to a higher value as described in the slow

start section.

Reno TCP shows a better and optimized performance than Tahoe TCP when a

single packet is dropped from a window of data. But the performance can be affected

when multiple packets are dropped from a window of data.

2.1.6.3 Vegas TCP

Vegas TCP showed a further 40% 70% improvement in the throughput as

compared to the Reno implementation of TCP [4]. A new retransmission policy is used in

Vegas. In Reno, the arrival of three duplicate ACKs trigger the process of retransmission,

but Vegas uses a time stamp for each packet sent to calculate the RTT on each ACK

received. If the difference between the timestamp for that packet and the current time is

greater than the timeout value, then Vegas TCP retransmits the packet without waiting for

the third duplicate ACK from the receiver. If there are any losses of ACKs since the

retransmission, then the segments are retransmitted without the wait for duplicate ACKs.

A comparison of the actual throughput and the expected throughput to the

threshold values is made and then the window size is decreased or increased linearly.

2.1.6.4 TCP-SACK

SACK stands for Selective ACKs [5]. Initially the base implementation of TCP

used the cumulative acknowledgement scheme, in which the non-contiguous segments









received after the highest numbered segment in sequential order, were not acknowledged.

This made the sender to either wait for one RTT to detect each lost packet or retransmit

the segments even though they have reached the receiver albeit in non-sequential order.

Thus the TCP-SACK option was introduced which could inform the sender about the

highest numbered segment received in order and the non-contiguous segments received.

Since this is an extension to the base TCP, some TCP versions may support it whereas

many may not. Hence it becomes essential at the time of the connection establishment to

decide whether both ends would follow the SACK option or not.

To indicate the non-contiguous segments received, the 40 bytes of TCP options in

the TCP header is made use of. A start block and an end block represent each block of

contiguous data in the set of non-contiguous data. The start block indicates the starting

sequence number and the end block represents the ending sequence number.

Sally Floyd has performed simulation-based comparisons of Tahoe, Reno and

SACK TCP [6].

2.1.7 TCP Connection Termination

* Since a TCP connection is full duplex, it needs to be shut down independently from
both ends.

* To close a connection, a FIN segment is sent across to the other end. The receiver
of FIN segment sends an ACK of the FIN segment. The end that issues the close
first performs the active close and the other end performs the passive close.

* After one end does the active close, the other end does the passive close.

* When the FIN segment is received, there will not be any more data flow from the
sender of the FIN segment.

* After an end sends across the FIN segment, it can still receive the data from the
other end. This is known as the half close connection when the peer that has sent
the FIN segment and received the ACK for the FIN, is waiting for the FIN segment
from the other peer.









The connection termination is shown in figure 2-2.

Peer A PeerB

close FIN



FIN ACK



FIN" close



FI-__ ACK




Figure 2-2: TCP Connection termination.

2.8 Shortcomings of TCP and the Origin of SCTP

For the last two decades, the TCP/IP suite (which is slightly different from the

OSI suite) has dominated the networking world. Either TCP (Transmission Control

Protocol) or the UDP (User Datagram Protocol) has been used widely used in

applications worldwide as a transport layer protocol. Some applications using TCP,

however, needed additional features than what TCP currently offered. There were a few

vulnerable factors about using TCP, which we will describe shortly.

Ivan quotes the following deficiencies in TCP [7]:

* Many applications such as the streaming video do not require the strict ordering of
segments before passing them on to the application. This produces Head-Of-Line
(HOL) blocking. In this case TCP would produce the unnecessary delay in strict
ordering. Therefore a transport layer protocol, apart from providing the connection
oriented features also needed to have an option of unreliable and non-strict or
partial order delivery of segments to the application.









* TCP treats data transmission as an unstructured sequence of bytes. Streams cannot
be logically demarcated and it is up to the application to insert their marks inside
the streams explicitly.

* TCP does not support the concept of multihoming. Multihoming is the ability of a
host to support multiple IP addresses. It is not possible to associate more than one
IP address of a host to one end as a part of the same TCP connection. Thus a host
with multiple interface cards will not be able to use all its IP addresses as a part of
the same TCP connection. The reason for using the multiple IP addresses as a part
of an association could be for the reasons of load sharing or fault tolerance. We will
discuss these issues in the coming sections.

* TCP is vulnerable to Denial-Of-Service (DOS) attacks or SYN attacks. This
happens during the three-way handshake of the TCP connection initialization. The
entity, which does the passive open of the TCP connection, always allocates
resources for an impending TCP connection after it receives a SYN segment and
responds with a SYN-ACK. The application that does the active open may not
respond with the ACK and may not complete the three-way handshake. This
activity, when repeated, may exhaust the kernel resources to start a fresh TCP
connection and ultimately it becomes impossible to spawn TCP connections.

* TCP does not allow applications to have control over the TCP timers like the
initialization timers, retransmission timers etc.


One of the main applications, which found these above features of TCP lacking,

was the transport of PSTN (Public Switched Telephone Network) signaling across an IP

network. Thus, to overcome all these deficiencies of TCP, MDTP (Multi-Network

Datagram Transmission Protocol) was introduced by Randall Stewart and Qiaobing Xie.

Later on, they modified this to introduce SCTP. SCTP was initially called Signaling

Common Transport Protocol. But later, it was realized that SCTP could be used as an

alternate for TCP for normal networking applications other than signaling transport. The

reasons being that it behaved in a similar manner as TCP in addition to overcoming the

above mentioned limitations. So it was renamed to Stream Control Transmission


Protocol.









SCTP is a very recent transport protocol dating back to October 2000 when Randall

Stewart et al introduced the RFC 2960 [8], which formally describes SCTP.

2.9 Features of SCTP

We describe below, the features of SCTP in contrast to deficiencies of TCP and the

general features offered:

* Head-Of-Line (HOL) blocking is eliminated by SCTP as it also provides an option
for both sequenced delivery of segments and unordered delivery of segments to the
application. It supports both TCP and UDP modes of delivery.

* Having separation between logically structured sequences of bytes called chunks,
preserves message boundary. Thus control information and the actual data can be
grouped into separate chunks.

* SCTP provides support for multihoming. During the phase of establishment of an
SCTP association, either side can include one or more IP addresses as a part of the
association. A feature to include the IP addresses dynamically in the middle of an
association is also being provided currently [9]. However as we will discuss later,
only one path between a pair of IP addresses is allowed to be the primary path for
communication between two end points. Using the feature of multihoming, the
probability of the data chunks that have been transmitted, reaching their
destinations will be increased [10].

* SCTP supports multiple streams of data in a single association. To create the
independence in data transmission and data delivery, two sets of sequence numbers
are used: a unique Transmission Sequence Number (TSN) for each data chunk and
a unique Stream Sequence Number (SSN) to identify a data chunk within a
particular stream [10].

* SCTP prevents the Denial-Of-Service attacks by using a 4-way handshake it uses
while starting a new association. We will describe the 4-way handshake in the later
sections of this chapter. Basically SCTP does not allocate any resources when it
receives an INIT (the equivalent of a TCP SYN) from a client. Instead it forms a
cookie that embeds all the information required for forming a connection
(information required to form a Transmission Control Block) and sends it across to
the client. Only when the client echoes back the cookie to the server, will the actual
allocation of resources take place at the server end.

* SCTP follows TCP- friendly congestion control algorithms. This includes the slow-
start, congestion avoidance and retransmission algorithms of TCP. SCTP also
derives the Selective Acknowledgement (SACK) derived from TCP. It provides a
GAP ACK block that includes information about non-contiguous segments that are
missing at the receiver end.









* SCTP has a Heartbeat chunk which are sent periodically along the different paths
of an association. By this mechanism it decides whether a particular endpoint or
interface of the other end has failed. This feature is currently used in SCTP as a
fault tolerance mechanism.

* User data is fragmented to fit the Maximum Transmission Unit (MTU) along a
particular route.

* A mandatory Verification tag field and a 32 bit check sum (Addler checksum) is
added to the SCTP header for validation after an endpoint receives a packet.

* Any application running over TCP can be ported to run over SCTP.


2.10 SCTP Association

The diagram below shows an overview of an SCTP association aggregating all the
features of SCTP that have been described above [8].


Figure 2-3. An SCTP association and its characteristics [8]


2.11 Packet Format of SCTP

Since SCTP can logically distinguish between the different chunks, the generic format of

an SCTP packet would be the common SCTP Header followed by its chunks.





















Figure 2-4: SCTP Packet format

2.12 SCTP Chunk Description

Each SCTP chunk is specific to its functionality. The Chunk has information

about the Chunk Type, different flags for that chunk, length of the chunk and the value of

the chunk (data). The general format of an SCTP chunk is shown below:


Figure 2-5: SCTP Chunk format [8]


* Chunk Type: This field is an 8-bit unsigned integer. There can be various chunk
types like INIT, DATA, INIT-ACK etc. A short description of some of the relevant
chunks is described in the next section.

* Chunk Flags: This is of 8 bits. This contains information pertaining to a particular
chunk.

* Chunk Length: This is a 16-bit unsigned integer and contains the length of the
chunk in bytes. This field does not include the length of the padding.

* Chunk Value: This is a variable length field containing the actual data to be
transmitted. The type of data it carries is dependent on the type of the chunk.


SCTP Corrrnon Header

Chunk 1

Chunk 2

Chunk 3










2.13 SCTP Common Header

SCTP Header is similar to the TCP Header with information such as the source

port number, destination port number, and check sum. It also contains the verification tag

for validation purposes. Fields such as Acknowledgement number, sequence number etc.

found in the TCP header are not found in the SCTP Header. Since there is message

preservation in SCTP and the existence of chunks, the individual chunks carry this

information. Figure 2-6 shows the SCTP Header.




Source Port Number Destination Port Number




Verification Tag



Checksum



Figure 2-6: SCTP Common Header format

* Source Port Number: This is a 16 bit unsigned integer. It contains the port number
of the SCTP sender.

* Destination Port Number: This is a 16 bit unsigned integer. It contains the port
number of the SCTP destination.

* Verification Tag: This is a 32 bit unsigned integer. This is used to check if the
packet is coming from a valid and right host. It contains the value that was agreed
upon while sending the INIT and INIT-ACK chunks during the initialization of the
SCTP association.

* Checksum: This is a 32 bit unsigned integer containing the checksum of the SCTP
Packet.









2.14 Various SCTP Chunk Descriptions

Depending on the value of the chunk type, we have various chunks that are

described in this section.

2.14.1 INIT Chunk

This chunk is analogous to the TCP SYN segment sent during the initialization of

the segment. This contains an initiate tag, used as a verification tag in all other segments

sent by the receiver of the INIT. The use of the verification tag has already been

discussed earlier. The number of inbound and outbound streams in the association is also

negotiated during the sending of this chunk. The INIT chunk also contains the receiver

window size that is advertised along with one or more IP addresses that would be used

during the association to support multihoming. The Initial Sequence Number (ISN) is

also a part of the INIT chunk.

2.14.2 INIT ACK Chunk

This chunk is sent in response to an INIT chunk. The format of this chunk is

similar to the INIT chunk except that it also contains the State Cookie, which is generated

by the sender of the INIT ACK chunk. As described earlier, this is a method to prevent

the Denial-Of-Service attacks.

2.14.3 DATA Chunk

This carries the user data along with the information such as the TSN

(Transmission Sequence Number), Stream Sequence number (since multiple streams can

be transmitted as a part of a single association) etc. The fields just described are

analogous to the Sequence number in TCP, except that they have been moved to the

chunks from the header portion.









2.14.4 SACK Chunk

This is the Selective Acknowledgement Chunk. As the name indicates, this chunk

is used to acknowledge data where the Transmission Sequence Number (TSN) of the data

received may or may not be in a sequence. To indicate non sequential data received, this

chunk has a GAP ACK block, which has a GAP ACK start number and a GAP ACK end

number indicating the TSNs of the chunks received. This chunk also has a duplicate TSN

block to let the sender know of any duplicate chunks received. It also carries the

Cumulative TSN ACK, which contains the TSN of the last DATA chunk received in

sequence before a gap.

2.14.5 HEARTBEAT Chunk

HEARTBEAT chunks are usually sent to detect the reachability of a destination.

This normally includes the information about the sender's current time when the

HEARTBEAT is sent.

2.14.6 HEARTBEAT ACK Chunk

HEARTBEAT ACK chunks are sent in response to HEARTBEAT chunks. It is

always sent to the source IP address of the datagram containing the HEARTBEAT chunk.

2.14.7 ABORT Chunk

ABORT chunks are sent to shut down an association abruptly. It also contains the

error code as to why the association was terminated. DATA chunks must not be bundled

with the ABORT chunk.

2.14.8 SHUTDOWN Chunk

SHUTDOWN is sent to facilitate a graceful shutdown of an SCTP association. It also

contains the Cumulative TSN Ack, which is the TSN of the last chunk received in

sequence before any gaps.











2.14.9 SHUTDOWN ACK Chunk

SHUTDOWN ACK is sent in response to a SHUTDOWN chunk.

2.14.10 SHUTDOWN COMPLETE Chunk

SHUTDOWN COMPLETE is used to acknowledge the receipt of the

SHUTDOWN ACK chunk. This is sent at the end of the shutdown process.

2.14.11 ERROR Chunk

ERROR chunk is sent to indicate to its peer end point of an error condition. There

can be various error conditions such as Unresolvable Address, Unrecognized parameters,

Out of Resource etc.

2.14.12 COOKIE ECHO Chunk

This chunk is used in the initialization of an association. The peer end wanting to

initiate an association sends this chunk. This completes the initialization process from the

client side. This chunk must be sent before any DATA chunks can be transmitted.

2.14.13 COOKIE ACK Chunk

COOKIE ACK chunk is sent in response to a COOKIE ECHO chunk. Again,

before any DATA chunks can be transmitted, this chunk should be transmitted.

2.15 SCTP Association Establishment

SCTP has a 4-way handshake unlike TCP's 3-way handshake in establishing an

association. The following are the steps involved in the 4-way handshake:

* One of the ends sends an INIT chunk with all the necessary information embedded
in it. The sender of INIT now starts a timer, T1-init timer and enters the COOKIE-
WAIT state.

* The receiver of the INIT chunk responds by sending an INIT ACK chunk. The
verification tag in the INIT and INIT ACK chunks is used for validation purposes
during future transmissions of data. The receiver now generates a cookie and









embeds in it, all the information needed to establish a TCB (Transmission Control
Block) and sends it along with the INIT ACK. No resources are allocated at the
receiver end for the TCB.

* When the sender of INIT receives the cookie from the peer end, it stops the T1-init
timer and sends the cookie back in a COOKIE ECHO chunk. After this it starts the
T1-cookie timer and enters the COOKIE-ECHOED state. The data transmission
can actually start with this chunk.

* After receiving the COOKIE ECHO chunk, the peer establishes the TCB and
changes to the ESTABLISHED state. It now sends a COOKIE ACK, which could
also be bundled along with other data chunks.

* When the other end receives the COOKIE ACK chunk, it now moves to the
ESTABLISHED state and stops the T1-cookie timer.


The diagram below shows the SCTP association establishment. The steps described

above can also be seen in the SCTP State diagram in the next section.


Peer A Peer B






DI1T ACK







COOKIE-ACK


Figure 2-7: SCTP Association establishment.









2.16 SCTP Association Termination

SCTP uses a 3-way handshake when the association has to be terminated unlike

TCP's four exchanges for complete termination of the connection. The steps for a normal

and a graceful shutdown are described as follows:

* The application issues a SHUTDOWN primitive to the SCTP asking it to shut
down the association. Since there is no concept of half closed states like in TCP, all
the data has to be flushed out before sending the SHUTDOWN chunk. It now
reaches the SHUTDOWN-PENDING state before the data is sent. After all the
pending data is sent, a SHUTDOWN chunk is sent and moves to the
SHUTDOWN-SENT state. It also starts the T2-shutdown timer.

* When the other end receives the SHUTDOWN chunk, it goes to SHUTDOWN-
RECEIVED state. Now it is this end's turn to send all the outstanding data to the
other end. Also the SHUTDOWN receiver must not receive any fresh DATA
chunks from the other end during this time. The SHUTDOWN sender now restarts
the T2-shutdown timer each time it receives fresh DATA chunks and responds with
a SACK. But the SHUTDOWN sender must not send data at this point of time. The
SHUTDOWN receiver now sends a SHUTDOWN ACK chunk and moves to
SHUTDOWN-ACK-SENT state.

* When the SHUTDOWN sender receives the SHUTDOWN ACK, it stops the T2-
shutdown timer and sends a SHUTDOWN COMPLETE chunk to its peer and thus
erases all traces of this association. Thus the association at this point of time is
completely broken down.


The diagram 2-6 shows the steps in the SCTP termination. These states are also shown in


the SCTP state diagram later in the chapter.










PPper A PRR"






SHL:TDOJV N'ACK



SHLTDOW'N CX3 MTP ETE





Figure 2-8: SCTP Association termination

2.17 SCTP State Diagram

The next two pages describe the SCTP State diagram, including the different

states that have already been discussed during the association initialization and

termination.











Receive INIT CLOSED Delete TCB Send ABORT
Generate Cookie II Delete TCB
Send INIT ACK

ASSOCIATE
Create TCB
Send INIT
Start Cookie Timer

Receive valid
COOKIE ECHO
Create TCB COOKE-
Send COOKIE ACK I


Recehie IIT ACK
Send COOKIE ECHO
Stop Init Timer
Start Cookie Timer



COOKlE-ECHOED



Receive COOKIE ACK
Stop Cookie Timer


Figure 2-9: SCTP State diagram


Receive ABORT


ABORT


















SHUTDOWN
Check outstanding
DATA chinks

SHUT
PENT


No more outstanding
Send SHUTDOWN
Start Shutdown-timer



SHUT
SENT


(A) Receive
SHUTDOWN ACK
Stop Shutdov,.n-aner
Send SHLT-DOXWN
COMPLETE, delete
TCB




(B) send SH-ITDO\\N
ACK
Start Shutdown-timer
Move to SHUTDO'N-
ACK-SENT


Receive
SHUTDOWN(B)


Figure 2-9: continued









2.18 SCTP Congestion Control

SCTP congestion control algorithms are very similar to the TCP congestion

control. It follows the slow start algorithm, congestion avoidance, fast retransmission and

recovery just like TCP. The one main difference between the TCP and SCTP congestion

control is that since SCTP supports multihoming, it is necessary to store and maintain the

congestion control parameters for all paths of a multihomed association. SCTP provides

for SACKs and GAP ACKs to indicate selective acknowledgement and gaps in the

received segments.

SCTP maintains three congestion control parameters:

* Congestion Control window (cwnd): This is maintained in bytes. This indicates a
limit of how many bytes the sender can currently send to the peer end, provided the
flight size and the receiver window permit it. Its function is similar to ssthresh in
TCP.

* Slow Start threshold (ssthresh): This is stored in bytes and is used to distinguish
between slow start and congestion avoidance. Its function is similar to ssthresh in
TCP.

* Receiver Window size (rwnd): This is the limit set by the receiver as to how many
bytes it can receive contingent on the buffer size and how much the application has
emptied the receiver buffer.


It is again emphasized that there are separate variables stored for each of the

destination addresses. But only one rwnd variable is kept. Apart from these variables,

another variable partial bytes_acked records the number of bytes that have been partially

ACKed by GAP ACKs and otherwise.

Slow start and congestion avoidance is similar to those of TCP except that

partial bytes_acked also comes into the picture as described in the steps below.









2.18.1 Slow Start

Slow start algorithm is used to probe a network initially before injecting data into it

because one is not aware of the conditions of the network initially.

* The initial cwnd is set to 2 MTU (Maximum Transmission Unit) bytes at the
start.

* After a retransmission, the cwnd is set to 1 MTU.

* The initial value of ssthresh is set to a high value like 65536.

* When the cwnd is less than or equal to ssthresh, then slow start algorithm is to be
used. If an incoming SACK advances the Cumulative TSN ACK point (which is
nothing but the highest TSN received in sequence so far), then cwnd must be
increased by a minimum of either the total size of the DATA chunks acknowledged
OR the destination path's MTU.

* When an endpoint does not transport data on a given address, the cwnd of that path
must be set to the maximum of (cwnd /2) OR 2 MTU per RTO (Retransmission
Time Out).


2.18.2 Congestion Avoidance

Congestion Avoidance is to be used when the value of the ssthresh is less than

cwnd.

* Initially partiallybytes_acked is set to zero.

* When cwnd is greater than ssthresh, each SACK that arrives increases
partially bytes_acked by the number of bytes acknowledged.

* When the sender has cwnd or more bytes of data outstanding and
partial bytes_acked is greater than or equal to cwnd, then increase cwnd by MTU
bytes and reset partial bytes_acked to (partial bytes_acked cwnd).

* Obviously when all the data has been acknowledged, partial bytes_acked is reset to
zero.

* Whenever data segments are indicated as missing by way of the SACKs or GAP
ACKs, i.e., whenever the number of 'missing segment' reports reaches four, then it
follows fast retransmission. Here the value of ssthresh is reduced to a maximum of
(cwnd / 2) and 2 MTU. The value of cwnd is now set equal to ssthresh, However
if the retransmission timer waiting on the ACKs expires, SCTP performs slow start









by setting cwnd to 1 MTU and ssthresh to a maximum of (cwnd / 2) and 2 *
MTU.

2.19 SCTP Fault Tolerance

Like TCP, SCTP makes use of HEARTBEAT chunks to find out if a particular

destination is still alive or not. This is analogous to the keep-alive timer in TCP. The

following steps describe the operation of the heartbeat mechanism in SCTP:

* During the setting up of an association, the periodic interval at which
HEARTBEAT chunks are sent to a destination is provided.

* After the heartbeat timer expires, the host sends HEARTBEAT chunks with the
timing information in it.

* If the HEARTBEAT chunk is not acknowledged with a HEARTBEAT ACK within
the RTO, then an error counter for that destination is incremented.

* When the error counter of a destination path reaches an upper bound,
Path.Max.Retrans, then that path is declared inactive.

* But when the HEARTBEAT ACK is received from the destination, then the error
counter is cleared.

* The receiver of the HEARTBEAT chunk copies the information from it onto a
HEARTBEAT ACK chunk.

* The application can set the interval HB.interval, i.e., the interval at which
HEARTBEAT chunks are to be sent out to a destination.

* Since the HEARTBEAT chunk contains the timing information as to when that
particular chunk was sent, the RTT (Round Trip Time) of that path can be
calculated and updated.


The SCTP HEARTBEAT chunks are similar to the TCP Keep-alive timer. The

option to enable the TCP keep-alive timer is provided by the setsocketO API of the

socket API. TCP sends a keep-alive packet periodically to check if the particular endpoint

is alive or not.









2.20 Security Issues in SCTP

SCTP mainly uses the verification tag and the cookie as security mechanisms in

addition to using the IpSec features of the network layer [11, 12]. SCTP as a protocol

does not define any new security protocols or procedures [10].

2.21 Key Points to Remember

In this chapter, we have discussed the basics of TCP, it's different flavors, the

congestion control algorithms in TCP. We also discussed SCTP, its different chunks and

establishment and termination of an SCTP association.. We also summarized the

differences between TCP and SCTP.

In a TCP connection, there exists only a single path of communication between

two endpoints because a TCP connection is strictly between an IP address and a port on

one end and an IP address and a port on the other end. It does not support the concept of

multihoming. Therefore the issue of multipath routing does not arise at all in TCP, as it

does not support multihoming.

But in SCTP, since it supports the concept of multihoming, there exists multiple

paths as a part of a single association. Thus we should be able to use the different paths

provided as a part of the association after evaluating each one of them. In this manner, we

are able to realize the true utilization of all the paths as opposed to using a single path

during the duration of an association.

The HEARTBEAT chunks that we described have a significant bearing on the

topic of this thesis. As we see in the next chapter, it is the HEARTBEAT chunks using

which we decide whether to switch over to a new path and make it the primary

communication path. We make use of the timing information and calculate the RTT, in






31


order to switch over to a path that has the least RTT. We will discuss more about this in

the next chapter.














CHAPTER 3
DESIGN OF NAIVE MULTIROUTING (MROUTE)

This chapter discusses the motivation for introducing the multirouting feature in the

SCTP protocol. It also explains the problems we faced with a naive multirouting feature,

which we called MROUTE. The categories of problems that we face in MROUTE and

the solutions that we propose are presented in the form of a matrix. The various design

issues and decisions that were made are also elaborated.

Table 3-1: Summary of the differences between TCP and SCTP.
TCP SCTP
Head-of-line blocking due to the strict Head-of-line blocking is eliminated as
ordering of segments produces unnecessary SCTP supports both the options of both
delay in certain applications, strict and non-strict ordering of segments.
It supports both a TCP mode and a UDP
mode of transmission.
Data transmission is treated as an Separation exists between logically
unstructured sequence of bytes with no structured sequences of bytes known as
differentiation between streams. chunks.
Multihoming support is not provided. Multihoming support is provided with the
ability to dynamically add/remove IP
addresses in the middle of an SCTP
association.
Vulnerable to Denial-of-Service attacks. Due to the cookie mechanism during the
initialization of the association, Denial-of-
Service attacks can be avoided.
Application control over the TCP timers Application control over SCTP timers is
does not exist. possible
Keep-alive timers are used to detect if a HEARTBEAT chunks are used to detect if
destination is alive or not. a destination is alive or not.
No scope for multipath routing as the Multipath routing is possible making use of
support for multihoming is not provided, the property of multihoming.
If the path of communication goes down, Through the support for multihoming, fault
there is no fault tolerance provided, as there tolerance is provided by means of the other
are no standby paths. paths functioning as standby paths.









In the previous chapter, we talked about TCP, SCTP and the differences between

them. The above table briefly summarizes the differences between TCP and SCTP.

3.1 Motivation for Multirouting

According to the SCTP RFC [8], there is only one active path where the primary

communication of data takes place during a SCTP association. If the association is

multihomed, the other paths exist just as standby paths. If the primary path goes down

due to some reason, a standby path is made the primary path.

The choosing of the primary path currently does not depend on any criterion. By

default the path connecting the source IP addresses of the datagram containing the INIT

and the INIT ACK chunks is chosen as the primary path for communication. The other IP

addresses, which exist as a part of a multihomed association, are specified in the INIT

and INIT ACK chunks. The other paths are never evaluated and come into play only for

the purpose of fault tolerance.

The network conditions such as failures and congestion change dynamically all

the time. Hence we argue that using just one primary path for communication does not

utilize the multihoming feature of SCTP completely. As a result, we propose that the

other paths should be evaluated and used, when they become better than the primary path

currently used for transmission. Now the question of how a particular path is chosen over

other paths comes into consideration.

3.2 Design of Naive Multirouting or MROUTE

We mentioned that the HEARTBEAT chunks are sent out periodically to detect

whether a particular destination is alive or not. We also recall that HEARTBEAT chunks

contain timing information and this is used to update the RTT (Round Trip Time)

estimators.









Round Trip Time is one of the critical factors influencing the throughput of data

transfer. If there are two paths of different RTTs, then the path with the lower RTT will

ultimately yield a higher rate of data transmission than the path with the higher RTT. The

RTTs of the various paths are updated when the HEARTBEAT ACK chunks arrive along

them. The RTT of the primary path is known since there is a regular flow of DATA

chunks along it. Thus the information about the RTTs of all the paths is available at any

point of time.

Hence whenever RTT of a particular path is updated we compare the RTTs of all

the paths and then decide whether primary path needs to be changed based on the

comparison. Whenever the primary path is changed to another path, then the data transfer

takes place along the new path chosen till another path of lesser RTT is available.

We now look at the various functions in the SCTP source code that are used when

the multirouting feature is introduced.

3.2.1 RttUpdate(

RttUpdate is a function that updates the RTT of a path, which it takes in as a

parameter. The function prototype is as follows:

void SctpAgent::RttUpdate(double dTxTime, SctpDestS *spDest)

* dTxTime is the time stamp information.
* SpDest is the destination, whose RTT needs to be updated based on dTxTime and
the current time.
3.2.2 ProcessHeartbeatAckO

ProcessHeartbeatAck, as the name suggests, is the function that is called

whenever a HEARTBEAT ACK is received in response to a HEARTBEAT chunk. In

short, this function clears the error counter associated with a specific destination and

based on the time stamp received, updates the RTT of the path. Error counter keeps track









of the number of times that the HEARTBEAT ACK was not received, before it declares

the other end as dead. The prototype of the function is as follows:

void SctpAgent::ProcessHeartbeatAckChunk( SctpHeartbeatAckChunk_S

* spHeartbeatAckChunk)

* SpHeartbeatAckChunk is the structure containing the HEARTBEAT ACK chunk.

3.2.3 SendBufferDequeueUpto(

When DATA chunks are transmitted, they are stored in the SendBuffer till the

other end acknowledges them. Whenever a SACK is received, then this function is called

to dequeue the DATA chunks from the SendBuffer. Only those DATA chunks that have

been acknowledged will be dequeued from the SendBuffer. After they are dequeued, the

RTT information is updated and the timer is stopped if the destination timer was still

running.

Thus we can see that there are two instances where the RTT information needs to

be updated. Both the ProcessHeartbeatAck( and SendBufferDequeueUptoo functions

need to call RttUpdateo as shown in the following diagram.


Figure 3-1: The calling of function RttUpdate









After the RTT information is updated in the function RttUpdate, we compare the

RTTs of all the paths. The multiple IP addresses of the peer end may be set up during the

association set up or by dynamically adding the IP address in the middle of an association

[9]. We then change the primary path of communication to the new path if it is found to

be of lesser RTT. Otherwise we continue transmission along the old path.

We call this the naive multiroute or MROUTE since we do not make any other

modifications to the code and expect it to prove beneficial in terms of the rate of data

transmission. Logically speaking, the change of path to that of a lesser RTT should

improve the performance with respect to the throughput or increased rate of data

transmission.

3.3 Problem Areas of MROUTE

We discuss the implementation details of MROUTE and other solutions in the next

chapter. Before going on to the next chapter, the problems that we faced with the naive

multirouting feature are listed. The problems associated with MROUTE can be

categorized into 4 classes:

1. Initial Cwnd Problem: The initial value of the cwnd of the new path determines
how many segments we transmit initially. Different solutions to start the cwnd of
the new path with a higher value are discussed. One of the solutions that we discuss
in this category is the hysteresis method, where history of collected data pairs of
(cwnd, RTT) would help in choosing an appropriate path.

2. Retransmission problem: As we will see in the analysis of our results in the next
chapter, retransmission of segments takes place due to segments on the new path
reaching the destination before earlier transmitted segments. Retransmission
consumes considerable time and network resources. Alternatives to prevent this
behavior are discussed.

Here we discuss the solutions of ignoring GAP ACKs (IGNORE) and preventive
retransmission in addition to the default, unmodified behavior of SCTP.

3. Cwnd growth: After we follow one of the solutions that we list for the Initial
Cwnd problem, the growth of cwnd from that point on affects the rate of data









transmission. We look at the different alternatives that can be followed for the
cwnd growth.

In this category, we address solutions like increasing the cwnd of the new path
based on the old path.

4. Oscillation: Basically this problem arises due to the occurrence of too many path
changes in a given time and may bring about instability in the system. The
Hysteresis method handles this problem to some extent. The research on this topic
is not carried out in this thesis and is reserved for future work.

3.4 Key Points to Remember

Solutions to the first three categories of problems are listed in table 3-1. We

address each of these solutions and discuss the pros and cons of each one of them in the

next chapter.

Table 3-2: A tabular representation of the solutions.

Initial Cwnd Retransmission
Method Path Default Hysteresis Old- Default Preventive Ignore
Change (1) Value path Retransmission GAP
(Y/N) ACKs
UNMOD N x x
MROUTE Y x x
IGNORE Y x x
INC Y x x
CwndOLD Y x x Or x

Cwnd Growth
Method Path Change Default Use SACKs to
(Y / N) increase cwnd

UNMOD x
MROUTE x
IGNORE Y x
INC Y x
CwndOLD Y x Or x

Default solutions in each of the categories shown above indicate the current,

unmodified default behavior of the SCTP protocol, which we call UNMOD. We have

named the different combinations of the solutions that we have tried out as UNMOD,






38


MROUTE, IGNORE and INC. As indicated in the table, the cross symbol (x) shows the

combination of solutions that we tried out for each of the methods that we mention.














CHAPTER 4
IMPLEMENTATION AND ISSUES OF MROUTE

We discussed the design of naive multirouting or MROUTE in the previous

chapter. We also addressed the problem areas in this design and came up with a tabular

representation of the different alternatives along with a brief introduction to each of the

problems. Before we elaborate on the details of the solutions, we give an introduction to

Network Simulator -2 (Ns-2) using which we carry out the simulations. This chapter is

concluded with a detailed network scenario description and comparison of the behavior

of MROUTE and UNMOD.

4.1 Introduction to Network Simulator (Ns-2)

Network Simulator, Ns-2, is an open source discreet event simulator tool targeted

at network research and provides substantial support for simulation of routing, multicast

protocols and IP protocols, such as TCP, UDP, SCTP, RTP over wired and wireless

(local and satellite) networks [13,14]. Ns-2 was developed by Information Sciences

Institute (ISI) at the University of Southern California (USC).

Tcl, pronounced tickle, stands for Tool Command Language and its associated

user interface is called Tk, which stands for toolkit. Tcl/Tk is one of the widely used

scripting languages used these days. Tcl is a simple programming language. Tcl scripts

are basically made of Tcl commands, separated by newlines and colons. The reasons for

choosing to use Tcl in ns-2 over any other programming language such as C, is that Tcl

provides a much simpler interface to the functionality and syntax. This does not require

the knowledge of any high-level programming language, compilers or linkers.









OTcl is an extension to the basic Tcl shell that provides the object-oriented features. OTcl

is a superset of Tcl, and has the same relationship as C to C++. Correspondence is

required between classes at the C++ level and their corresponding OTcl classes. TclCl is

responsible for providing the link. In summary, Ns-2 requires the following packages to

run: Tcl release 8.3.2, Tk release 8.3.2, OTcl release 1.0a7 and TclCl release 1.0bl

Ns-2 is written in and C++ and Otcl. The use of OTcl enables the networking

components to be defined as OTcl classes. Simulation scripts are programmed in OTcl

scripting language. Apart from simulating the network protocols, the traffic source

behavior (e.g., Variable Bit Rate (VBR), Constant Bit Rate (CBR)), router queue

management mechanisms, routing algorithms, multicasting protocols, MAC layer

protocols, etc., can also be simulated by the Ns-2 tcl scripts.

For the reasons of scalability, extensibility and efficiency, Ns-2 uses a split-

language approach, using two languages, C++ and OTcl as a part of its architecture. The

control path implementation is separate from the data path implementation. C++ code

runs fast, making it ideal for protocol implementations. And OTcl can be modified

quickly, thus making it suitable to write the Tcl scripts. Hence, if there is a need to

process a packet or change the implementation of an existing protocol stack, C++ is used.

OTcl is used as an interface to interact with the protocol code through the Tcl scripts

written for simulation, configuration set-up, etc.






















Figure 4-1: Ns-2 interaction interface between OTcl and C++.

As we can see, a Tcl script written for simulation interacts with the Otcl layer,

which internally creates a correspondence to the C++ object through the OTcl linkage.

The event scheduler and the basic network components of the data path are implemented

and compiled in C++ and are made available to the outside world through their

corresponding OTcl objects through the OTcl linkage. Thus the control methods and the

class variables of the C++ object now become accessible through the member functions

and variables respectively of the OTcl object.

4.1.1 Writing a TCL script for ns-2

4.1.1.1 Creating the Event Scheduler

An event scheduler tracks the simulation time and triggers the various events

scheduled to occur at particular time intervals. It fires the events in the event queue at

particular times by invoking various network components and execute the appropriate

action as specified.

An event scheduler is created by the command: set ns [new Simulator]

An event is scheduled by the command: $set at