Internet Research Group at Clemson University Issues associated with Application Level Metrics and Assessments for Transport Services – An Overview Kalyan CHINTALAPATI 7/18/2019 Internet Research Group at Clemson University

Let me ask you something Suppose that you approach an ISP and ask him/her about their dial-up connection. ISP: We guarantee you a maximum bandwidth of 56.6Kbps. You: Then what about the access ? ISP: it is “fast”. You: How “fast”? ISP: Well...err...umm.. It is “Fast”...<<that's all he/she can tell you about it>> Now consider the case where a multi-national firm wants to build a world-wide-intranet and they approach the service-provider and ask them the same questions and imagine their reaction if they get the same answers. 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University Project Goals Develop web-based metric (s) at the application-level, which we think reflect the Quality user experiences. And for this purpose, we need to analyze network traces for which we need a tool. The traces that we intend to collect will be over different setups – traces collected at a DSL site /Dial-Up site etc and traces collected while running different combinations of the popular browsers over different OSs like IE6.x/WinXP, Netscape 6.x/Linux 8.0 (RedHat), Netscape 6.x/Win2000... Why? Current metrics being used are based on PING Remember last Thursday CSDHCP27 aka neo, Problems... 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University Description So, the primary goal we have in mind now is to develop a tool which does the processing of traces and gives us the results in the format we want. For that we have selected RApid Model Parameterization tool aka RAMP. We have chose RAMP because it has the capability to quickly parameterize models from data and it already deals with both the network level as well as user level. RAMP can convert live measurements into simulation models which then be used to generate realistic synthetic traffic. 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University RAMP The input of RAMP is a tcpdump-format file, recorded at a single tap point of the network, that contains only TCP/IP header information. The output of RAMP is a set of CDF (Cumulative Distribution Function) files that model the corresponding traffic. Specifically, the CDF files consist of two types of data. One set of CDF files model user/application level statistics of the traffic, such as user session arrival, page/file size etc. 7/18/2019 Internet Research Group at Clemson University

RAMP – the tool we intend to modify/re-engineer Net work characteristics Link BW # of nodes RTT User behavior # of users User inter-arrival # of page per user Page size Page arrival # of Object per page Object size Object arrival tcpdump trace RAMP NS 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University RAMP – The Working (1) filter tcpdump trace for TCP port 80 (2) run http_connect OUTPUT: summary of http connections (3) run http_active OUTPUT: summary of http client request & server response (4) compute delay based on each SYN/SYN-ACK pair OUTPUT: CDF that characterizes the averaged RTT (5) compute and output CDF files that model Web traffic 7/18/2019 Internet Research Group at Clemson University

To do <<immediately>> We intend to develop an ad hoc method to collect data this month (from 2 clients in our lab, 1 dialup (how to do this??), and 1 DSL connected client). This will help us 'prototype' our method and get some data quickly. Phase 2 might be an improved collection method, additional clients/servers and a longer collection period. Then phase 3 is to take the analysis into the outer lab. 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University Current Status Having gone through the RAMP code, we have an understanding of how it works. Now, we are trying to extend RAMP to gather “loss” statistics. Also, we have to gather the tcpdumps over different platforms/browsers and at different sites while collecting PING-based statistics at the same time. We still need to figure a way to do that in a timely fashion, i.e., open the browser and visit a given number of sites <<homepages and some random links on their homepages>> 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University RAMP does not deal with “loss”, but we will have to define what we mean by loss. Because, we just have the traces collected at the user-end. So, how do we identify “loss” at the user-end ? Currently my work is headed in the direction of defining a heuristic for “loss” and extend RAMP to feature “loss” statistics. 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University Loss Contd... There are a variety of TCP/IP Protocol stacks over the internet and different OSs (ab)use them in their own way. A study by Sally Floyd and Jitendra Padhye (On Inferring TCP Behavior), they have gathered statistics over 6000 webservers all over the world and the table shows the usage of each TCP stack. 7/18/2019 Internet Research Group at Clemson University

Internet Research Group at Clemson University Loss Contd... In Tahoe TCP - Retransmit Timeout before the retransmission of lost packet, but under certain conditions it goes for an unnecessary retransmission. In NewReno TCP- a Fast Retransmit for the lost packet, no additional Fast Retransmit or Retransmit Timeouts, and no unnecessary retransmissions. In Reno TCP - a Fast Retransmit for the lost packet, a Retransmit timeout, no unnecessary retransmissions. 7/18/2019 Internet Research Group at Clemson University

Questions, Comments and Suggestions... 7/18/2019 Internet Research Group at Clemson University