Analyzing QUIC in Wireshark

[Illona Popic]

Hello,

I am doing a research on YouTube using QUIC for content delivery and I'm wondering if there is a way to find out which and how many packets were retransmitted, lost etc., looking at the traffic captured with Wireshark?

Thank you in advance!

[Jo Kulik]

Not necessarily with wireshark.  If you're just sniffing packets off a wire, you can get some sense of the data delivery rate at the link you are sniffing.  And you can get some sense of the acknowledgment rate there.  But you'll have no idea what those acknowledgments contain.  If there were losses, that would be hard to infer.

I mean, if you knew QUIC was doing Cubic, you might be able to infer from some packet send/receive times and ack traces that backoffs must be happening in response to loss.  But we run experiments with congestion-control all the time--you can't assume strictly Cubic.

What is the scenario that you are trying to measure?  How much control do you have over the receiver in this case?

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

[Illona Popic]

Thank you for your response.

I am actually trying to figure out how YouTube Android player deals with different bandwidth scenarios - when it's low or variable. I did not find a way to note quality switches during playback of videos because everything (client requests urls) is encrypted and API doesn't offer that option. 

I am trying to figure out which traffic features would be worth looking at, besides from average packet size, average interarrival time of packets etc. With TCP I was taking number of retransmissions and duplicate acknowledges into account and now I'm trying to find an alternative for that...

On Wednesday, March 8, 2017 at 12:34:40 PM UTC+1, Jo Kulik wrote:

Not necessarily with wireshark.  If you're just sniffing packets off a wire, you can get some sense of the data delivery rate at the link you are sniffing.  And you can get some sense of the acknowledgment rate there.  But you'll have no idea what those acknowledgments contain.  If there were losses, that would be hard to infer.

I mean, if you knew QUIC was doing Cubic, you might be able to infer from some packet send/receive times and ack traces that backoffs must be happening in response to loss.  But we run experiments with congestion-control all the time--you can't assume strictly Cubic.

What is the scenario that you are trying to measure?  How much control do you have over the receiver in this case?

On Wed, Mar 8, 2017 at 6:01 AM, Illona Popic <illp...@gmail.com> wrote:

Hello,

I am doing a research on YouTube using QUIC for content delivery and I'm wondering if there is a way to find out which and how many packets were retransmitted, lost etc., looking at the traffic captured with Wireshark?

Thank you in advance!

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

[Jo Kulik]

Do you have an unlocked Android phone?  Do you have experience using the android debugger?

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[Illona Popic]

I have an unlocked Android phone. I have only some basic experience with Android debugger.

[Jo Kulik]

I believe there are some options that you can turn of for the YouTube app for turning on the Chrome "--netlog" so you can look at client side packet traces for QUIC.  Would that be helpful?

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[Illona Popic]

Thank you for suggesting Chrome netlog, it looks like it could be helpful, but I can't find a way to log events for an Android app. I am using native Android YouTube player embedded in my own app.

[Jo Kulik]

Sigh, I spoke too soon.  The YouTube app has not yet exposed these knobs.  :(  (These knobs available in other Chrome/Cronet apps, but not yet YouTube).

In theory, if you could get the client app to expose its keys, then you can pass those to wireshark'ed packets from your client.  But AFAIK, that is also not yet supported.

So, yep.  It appears that you are in the dark as far as re-transmissions go.

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.

[Illona Popic]

It appears that I am! But thank you in any case for your help :)

[Tobias Kröber]

Hi Illona,

not sure if it answers your question but for everyone else being interested in checking for lost packets based on Chrome, it might be worth having a look at chrome://net-internals/#quic - at least it lists a column "Packets Lost" for QUIC streams. However, I haven't been playing around with it yet.

Kind regards,

Tobias

[Jo Kulik]

That's a great idea, in general, but unfortunately won't work for a Cronet app, like the YouTube Android app.

Tobias

To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+unsubscribe@chromium.org.