Summary of Projects
Sandhya G
ME (Computer Science)
IISc, Bangalore
Summary









Design and Analysis of Rate Aware Ad Hoc 802.11
networks
Secure NFS
OS Fingerprinting tool
Compiler Compiler in Python
Code generator for C
Check pointing utility
Search efficiency in indexing structures for similarity
searching
Source Code Search Engine
ELECTRON
Design and Analysis of Rate Aware Ad Hoc
802.11 Networks
M E Project
Contributions



Developed a WLAN MAC simulator
Added multi-rate support to the wireless extensions
to ns2.
Proposed a multi-rate aware IP stack.

L2 layer
•

Proposed an automatic rate switching mechanism which
could be implemented using the statistics available at the
device driver.
L3 layer
•
Proposed transmission time as a metric to guide routing
decisions.
Use link quality to guide routing
Use link quality to decide the tx rate
IP
Datalink
802.11 – A Brief Overview
802.11 PHY

PHY supports different data rates




802.11b – 1Mbps, 2Mbps, 5.5Mbps, 11Mbps
Lower data rates – larger coverage
Higher data rates – high throughput
Issue

Find the optimal transmission rate.
Modulation
DBPSK
DQPSK
CCK
Rate
1Mbps
2Mbps
5.5Mbps, 11Mbps
802.11 MAC
Uses CSMA/CA for transmission
ACK required for DATA packets
Two schemes
RTS/CTS Scheme(RCS) - RTS/CTS handshake
Basic Access Scheme(BAS) - no RTS/CTS handshake (small pkts)
Retransmissions at MAC level
Retry limit – 7
Congestion window (32 to 1024) incremented with each retransmission
DIFS
Backoff
SIFS
DATA
RTS
CTS
SIFS
ACK
SIFS
Modes of Operation
Infra-structure mode
Ad Hoc mode
WLAN MAC Simulator
Performance Analysis of DCF
Analysis







P0 + P1(1 − P2) + P2P1(1 − P3) +
P3P2P1(1 − P4) + P4P3P2P1(1 − P5) + P5P4P3P2P1(1
− P6)(1 + P6 + P62 ) + P5P4P3P2P1P63 = 1
effSBAS = average system delay + Psucc(S
+ SIFS + ACK) + Pcoll(S + AckTimeOut)
effSRTS = average system delay + Psucc(RTS + CTS +
S + ACK + 3*SIFS) + Pcoll(RTS + AckTimeOut)
where
S – time to send a data packet
Psucc – Probability of successful transmission
Pcoll – Probability of collision
WLAN MAC Simulator


Predict the throughput of WLANs
Used at Wibhu Technologies, Pune for
throughput computations.


Generalized the model for infra-structure
networks.
Assumptions


System operates in saturated conditions.
All stations transmit at the same rate (11Mbps).
Parameter
Value
PHY
DSSS
Slot time
20 µs
Cwmin
32
Cwmax
1024
Packet Payload
512B, 1024B, 1500B
MAC header overhead
34B
PHY header overhead
192b
LLC header overhead
8B
IP + TCP hdr overhead
40B
RTS
160b + PHY hdr
CTS/ACK
112b + PHY hdr
AckTimeOut
334 µs
CTSTimeOut
334 µs
Channel Bit Rate
11Mbit/s
SIFS
10 µs
DIFS
50 µs
No of retries
7
BAS Throughput
RCS Throughput
Performance Anomaly

Assumptions



One station transmits at 1Mbps.All others at 11Mbps
System operates in saturated conditions.
effSBAS = average system delay + Psuccslow(Sslow +
SIFS + ACKslow) + Psuccfast(Sfast + SIFS + ACK) +
Pcollslow(Sslow + AckTimeOut) + Pcollfast(Sfast + AckTimeOut)

effSRTS = average system delay + Psuccslow(RTSslow
+ CTSslow + Sslow + ACKslow+ 3*SIFS ) +
Psuccfast(RTSfast + CTS + Sfast + ACK + 3*SIFS)
+ Pcollslow(RTSslow + AckTimeOut) + Pcollfast(RTSfast +
AckTimeOut)
Performance Anomaly
Rate Switching Mechanism
Design

Highly adaptive rate control mechanism required


Modern WLAN products provide rate control support as part of
chipset
But cards like Atheros do not have rate control support
•


FER based design
Statistics available at device driver

Successful transmission
•


Alternative - Provide at device driver level.
Number of retries
Frame Error
When to switch the rate?


Frame Error
Successful transmission with more number of retries
Analysis – Basic Access Scheme
Packet Size = 512B
Packet Size = 1024B
Analysis – RCS Scheme
Packet Size = 512B
Packet Size = 1024B
Rate Switching State Machine
Simulation

Modified wireless extensions to ns2 to add


Multi-rate capability
Proposed state machine
Simulation Parameters
Number of Hops
2
Routing Protocol
DSDV
Propagation Model
Shadowing
Traffic (TCP)
FTP
Traffic (UDP)
CBR
Packet Size
1024
SUCC_THRES
50
ERR_THRESHOLD
1
Simulations
TCP Throughput
UDP Throughput
Implementation in device driver

Each node maintains a table at link layer to
keep track of rate to its neighbors

Experimental Setup


Two node setup – one equipped with SparkLAN
and other with DLink DWL 650+
Iperf traffic used
TCP Throughput
Link quality as routing metric
Ad Hoc Routing


Dynamic routing protocols used.
DSDV




Periodically exchange probe messages
Advertise routes with metric
Route Entry accepted if new seq no.or current seq no with
better metric
Metric part incremented by one to compute minimum hop
metric
Destination
Next Hop
Seq No
Metric
192.168.16.2
192.168.16.2
23
1
192.168.16.5
192.168.16.2
21
2
.
Typical DSDV Routing Table
Routing metrics
Minimum Hop count
Link Quality
Rate metric
Transmission time (Xtime)
•Minimize air time
•Takes into consideration
Link rate
Contention for channel
Asymmetry of links
Modifications to DSDV


If route entry accepted, metric incremented by link
cost, in the case of rate and Xtime metrics
Computation of Link Cost

Rate Metric
•

1/r * 10
Xtime Metric
•
•
•
•
Rate
Link Cost
11Mbps
1
5.5Mbps
2
2Mbps
5
1Mbps
10
current_xtime = Pxtime/packetsize
new_link_cost = w * old_link_cost + (1 − w) * current_xtime
link_cost_initial = 1/r * 10
Smoothing factor w = 0.85
Implementation in Click
Neighbor
Rate
State
Link
Cost
Timer
00:0D:88:C0:AA:75
55
STATE_55
2
T1
00:0D:88:F3:F0:D4
1
STATE_10
10
T2
.
.
Experiments

5 nodes equipped with SparkLAN and
DLink DWL 520+ cards

Netperf used for generating traffic
Scenario 1
TCP Throughput
1 connection (A – C)
3 conns (A–B, B-C, A-C)
Round Trip Delay
Scenario2
TCP Throughput
1 connection (A – C)
5 conns (A–D, D-B, B-E, E-C, A-C)
Round Trip Delay
Conclusions

The automatic rate control mechanism
results are close to that of Manual
configuration and simulation results are
comparable to the real world experiments

Xtime metric is found to perform consistently
well across the different scenarios
considered
Other projects
Secure NFS

Goal:



Secure all NFS transactions
Secret key established using DiffieHelman.
All transactions secured using RC4.
OS fingerprinting tool

Goal:


Utilize TCP inflexible parameters to
identify remote system.
Used window size to predict the OS.
Compiler compiler in Python


Tool similar to lex yacc in C.
Input


Regular expression and Grammar.
Output

LALR parser
X86 Code Generator for C

Input


Output




Three address code
X86 assembly code
LANCE used as front end to generate three
address code.
Machine independent optimizations like global dead
code elimination, constant propagation, loop
invariant code motion has been done.
Implemented register allocation schemes.
Check pointing tool



Allows to check point a process at an
arbitrary location and resume the
process at a later stage.
Core saved when we do a checkpoint.
It is replaced when process resumes.
Search efficiency in indexing structures
for similarity searching

Motivation


Need for similarity searching in new application
domains like multi-lingual databases.
Issue:
•

Way Out
•

Expensive distance computation.
Similarity Indexing structures
Analysis of various indexing structures

BK Tree, FQ Tree, Bisector tree, M Tree, VP
Tree, Clustering…
Search efficiency in indexing structures
for similarity searching


Distance function satisfies following conditions

Symmetry d(a,b) = d(b,a)

Non Negativity
If (a != b) d(a,b) > 0
else d(a,b) = 0
 Triangle Inequality
d(a,b) <= d(a, c) + d(c, b)
Search pruning criterion

d(q, x) > e

d(q, p) <= d(q, x) + d(x, p)
d(q, x) >= d(q, p) – d(x, p)
d(q, x) > d(q, p) – k

d(q, p) – k > e
Example: BK Tree
p0
1
p11
2
p12
n
…
p1n
Pruning criterion
d(p, q) – e <= i <= d(p, q) + e
Search efficiency in indexing structures
for similarity searching
Source Code Search Engine

Goal


Search for source code in the web
Two subsystems

Front end
•

Passes query to the search engine and
presents to user
Crawler
•
Crawls the web, indexes and stores in
database.
Source Code Search Engine
ELECTRON – The E Market

Two subsystems

Front End
•

Accept the requests from buyers and sellers
Backend
•
Implement the Business Models



Kasbah
Procurement
Transactions secured using digital
envelope.
ELECTRON - Front End
ELECTRON - Back End
Thank You