This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Checking the flow duration in Wireshark

0

I have collected 2 traces, 1 for a web page: aftonbladet.se and other for a video from youtube. I had read in an IEEE paper that for the web page the flow duration is shorter as compared to the flow duration for a video. My question is how do I check the flow duration from the 2 traces I have collected in Wireshark?

asked 24 Oct '13, 20:07

ron1's gravatar image

ron1
11112
accept rate: 0%


One Answer:

0

I had read in an IEEE paper that for the web page the flow duration is shorter as compared to the flow duration for a video.

What kind of paper is that? Do you have any link to that?

The reason I ask: It's totally obvious, that accessing a 'regular' web page generates a much shorter 'flow' (TCP connection) than a video (which lasts several minutes or even hours).

My question is how do I check the flow duration from the 2 traces I have collected in Wireshark?

Take a look at the conversations.

Statistics -> Conversation List -> TCP

or

Statistics -> Conversations -> TCP [a tab]

There is a column called 'Duration'. Compare that for the two conversations.

Regards
Kurt

answered 28 Oct '13, 08:50

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hello Kurt, Thanks for telling. I wanted to compare the flow duration between a web page(say CNN.com) and a requesting a video on youtube(from a web browser), I hope you get my point.

I had one more question, I have also read an article where it mentions that web page have multiple flows as compared to web video (which has less flows) My whole intention here is to identify web services by these characteristics, (flow duration, multiple flows). Is there any provision in Wireshark to see the occurence of multiple flows? It would be great to have some help on this. Regards, Rohan

(28 Oct '13, 09:18) ron1

I hope you get my point.

yes, see my answer (Statistics -> Conversation)

I have also read an article where it mentions that web page have multiple flows as compared to web video (which has less flows)

It depends how you define a 'flow'. If that's a TCP connection for you, then yes, loading a web site will create several tcp connections, at least in most of the cases. Try it with www.wireshark.org. See what get's loaded ;-)

My whole intention here is to identify web services by these characteristics, (flow duration, multiple flows)

Based on my experience: That's by far not sufficient to identify anything ;-)

Is there any provision in Wireshark to see the occurence of multiple flows?

Again, how do you define a 'flow'? If it's just TCP connections, then take a look at the 'Conversations' I mentioned in the answer.

(28 Oct '13, 09:26) Kurt Knochner ♦

Yes I get that point you have mentioned regarding the flow duration. My intention here is to give a higher priority to web page as compared to, say, video, VoIP etc. So I want to examine the following things: I want to implement the web traffic identification methods I proposed (data flow duration and multiple flows) and test this, via Wireshark, on actual traffic, due to which web traffic would get a higher priority as compared to other traffic(video VoIP). And, the HTTP GET message sent on port 80 is able to identify the web traffic, so I want to compare the above 2 methods (flow duration and multiple flows) to see whether these 2 methods(flow duration and multiple flows) can be used to identify the web traffic, and if yes, will it give i higher priority to the web traffic over other services. So can you help me on this?

(08 Dec '13, 18:57) ron1

I made your answer a comment ron1 (as it was a comment to Kurt's answer). A few questions/comments in response to it though:

  • Why would you ever want to prioritize HTTP over VoIP or video? In almost all situations, you should do the opposite because those are real-time applications that need low-latency more than HTTP traffic does.

  • Unless your network is actually congested, configuring QoS to prioritize HTTP traffic will have no affect. You need to have contested bandwidth between these applications for that to make a difference.

  • The time it takes to load a webpage does not always have the network as the bottleneck. If the page you're calling requires the web server to consult an application and/or database to get the information to present to the user, for example, tweaking network priorities will not improve the performance.

(08 Dec '13, 19:43) Quadratic

My intention here is to give a higher priority to web page as compared to, say, video, VoIP etc.

O.K. in that case I'll repeat my statement: Based on my experience, flow duration and flow count is by far not sufficient to identify anything ;-)

Of course, in general, HTTP requests will be much shorter than a video stream. However: There are also long lived HTTP connections, if you download a large piece of content, which can also be a video! Then, how do you differentiate a long video stream from a long VoIP call, only by looking at the flow count (1 for both) and the flow duration (maybe the same)?

Furthermore, if you want to use flow duration for QoS (Quality of service), that won't work at all.

Reason: To know the duration of a connection, you'll have to wait until it ends (or at least long enough the classify it as a 'long lasting' connection). However, then it might be to late to apply any traffic shaping (for sure if the connection has ended). So, the flow duration is really useless for QoS, except for a few uses cases, where you want to apply some kind of quota.

To be able to implement an efficient QoS policy, you need to identify the protocol as fast as possible at the beginning of the connection. That is usually done by analyzing

  • protocols
  • ports
  • signature bytes (like HTTP GET, SMTP commmands, Mime-Types, etc.)

I don't want to discourage you, but based on the information you provided so far, I suggest to look for other ways to classify content (HTTP, video, voip), than trying to use flow duration and flow count, as that's not going to work very well. I would even say: It's not going to work at all.

You wrote

I had read in an IEEE paper that for the web page the flow duration is shorter as compared to the flow duration for a video.

I asked for the link to that paper. Could you please post it here? I'm interested in what they were looking at and what the results were.

Cheers
Kurt

(08 Dec '13, 23:56) Kurt Knochner ♦