Streaming via quic_server

1,930 views
Skip to first unread message

Sushant Mongia

unread,
Mar 28, 2017, 12:07:46 PM3/28/17
to proto...@chromium.org
Hi All,

Thank you for your insightful posts over here. This has truly shed some light on my path.

For Brevity:

1) I want to run the index.html file in the quic_data, via a browser on an external host and that wireshark can detect the QUIC packets.
2) I want to find a way to run MPEG-DASH videos and a javascript client (Dash.js) on the quic_server, again so that wireshark can detect the QUIC packets.

A bit more in detail:

I probably have the most sought after question, I want to stream a MPEG-DASH video using a javascript based player and quic_server. Now, I've already implemented the whole setup using apache server separately (should you wanna refer to that), and I have everything else like encoders, content generators and clients set up and running. But, I wish to find a way for it to run via the quic_server.

This is how far I've gotten: Followed the guide from here, got things working on a local host, as in was able to fetch the index.file being pointed by the quic_respons_cache_dir with the quic_client , but thats about it. If I load it via the Chromium Browser it doesn't open up,

My first aim is to get that(index.html) out there via a browser and it to show QUIC packets in wireshark. How to go about doing that?

The Dilemma : MPEG-DASH has a set of bitrates and each bitrate has tonnes of segments and other files. Theoretically, if I put everything in the quic_respons_cache_dir with manually editing each file ( out of the gazillion files ) to add the X-Original-Url, it should work, shouldn't it?

Can you suggest me or point me to the right direction where I should be looking into?

I have done my research though,
This post by Wesley Davison : Makes me wonder do I have to append the header file to each file ( which is tedious for me ) or is there a way, maybe by using my content from Apache server and use a Shaka Player?

To summarize,
QUIC packets via Browser and QUIC packet via Dash.js client.

I hope I am not bothering you with this long a mail, I would love to hear your opinions, thoughts and ideas on this!

Best
Sushant

Gregory Ray

unread,
Mar 28, 2017, 2:37:23 PM3/28/17
to proto...@chromium.org
Last I checked Chrome only has Google domains whitelisted for Quic, are you passing the appropriate flags to enable for your Apache site?

chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --enable-quic \
  --origin-to-force-quic-on=www.example.org:443 \
  --host-resolver-rules='MAP www.example.org:443 127.0.0.1:6121' \
  https://www.example.org


On Tue, Mar 28, 2017 at 9:07 AM, Sushant Mongia <sushan...@gmail.com> wrote:
Hi All,

Thank you for your insightful posts over here. This has truly shed some light on my path.

For Brevity:

1) I want to run the index.html file in the quic_data, via a browser on an external host and that wireshark can detect the QUIC packets.
2) I want to find a way to run MPEG-DASH videos and a javascript client (Dash.js) on the quic_server, again so that wireshark can detect the QUIC packets.

A bit more in detail:

I probably have the most sought after question, I want to stream a MPEG-DASH video using a javascript based player and quic_server. Now, I've already implemented the whole setup using apache server separately (should you wanna refer to that), and I have everything else like encoders, content generators and clients set up and running. But, I wish to find a way for it to run via the quic_server.

This is how far I've gotten: Followed the guide from here, got things working on a local host, as in was able to fetch the index.file being pointed by the quic_respons_cache_dir with the quic_client , but thats about it. If I load it via the Chromium Browser it doesn't open up,

My first aim is to get that(index.html) out there via a browser and it to spit out the QUIC packets in wireshark. How to go about doing that?


The Dilemma : MPEG-DASH has a set of bitrates and each bitrate has tonnes of segments and other files. Theoretically, if I put everything in the quic_respons_cache_dir with manually editing each file ( out of the gazillion files ) to add the X-Original-Url, it should work, shouldn't it?

Can you suggest me or point me to the right direction where I should be looking into?

I have done my research though,
This post by You : Makes me wonder do I have to append the header file to each file ( which is tedious for me ) or is there a way, maybe by using my content from Apache server and use a Shaka Player?


To summarize,
QUIC packets via Browser and QUIC packet via Dash.js client.

I hope I am not bothering you with this long a mail, I would love to hear your opinions, thoughts and ideas on this!

Best
Sushant

--
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.

Sushant Mongia

unread,
Mar 31, 2017, 12:46:16 PM3/31/17
to QUIC Prototype Protocol Discussion group
Thanks for the prompt reply Gregory, Yes I did the same thing, with few modifications:

google-chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --enable-quic \
  --origin-to-force-quic-on=<my_website_name>.com:443 \
  --host-resolver-rules='MAP <my_website_name>.com:443 127.0.0.1:6121' \
  http://<my_website_name>.com/index.html

1) google-chrome instead of chrome
2) <my_website_name>
3) http instead of https

Note: I didn't register the domain name with a DNS after buying it. The <my_website_name>.com is just running on my apache server.
Assuming that isn't creating a problem, what else am I missing in the setup?

Just as a side note:
Here's what I've done till now,
1) Building Chromium on Linux: Installed Chromium from here
2) Playing with QUIC: Followed this for quic_server and quic_client
3) Linux Cert Management: Did this after making a folder for <my_website_name>.com in the quic_respons_cache_dir
4) I am able to get the index.html file from the quic_client (assuming it came via QUIC protocol) but I'm not able to get the same via google-chrome.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.

Gregory Ray

unread,
Apr 1, 2017, 2:05:29 AM4/1/17
to proto...@chromium.org
Hi Sushant,

The TLS handshake might be using DNS to validate the certificate, what is the common name of your certificate, does it match? Try adding an entry to your /etc/hosts with the common name routing to 127.0.0.1. Do you see any quic connections showing in chrome://net-internals/#quic?

You might want to try to connect to it from a different client as well, I find the go-lang quic implementation to be easier to weild, here is the client code: https://github.com/lucas-clemente/quic-go/blob/master/client.go

Might be useful to examine the UDP, something like this might work for nix/mac:
sudo tcpdump -i en0 'udp port 8000' 

Thanks,
Gregory

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

Jo Kulik

unread,
Apr 1, 2017, 11:20:12 AM4/1/17
to proto...@chromium.org
Client-side, I would also recommend turning on Chrome net internals to grab logs:


I believe you can also turn on logging via the chrome command-line with:

--log-net-log=<pathtofile>

Sushant Mongia

unread,
Apr 4, 2017, 5:20:16 PM4/4/17
to QUIC Prototype Protocol Discussion group
Hey Gregory,

Finally! I got past step 1. I was able to implement QUIC at a basic level, i.e. run a sample page from the quic_respons_cache_dir via the quic_server and open it via google-chrome. It was perhaps the common name that had to be added with 127.0.0.1, and it worked like a charm. My CN is <my_website_name>.com .
Kudos to your perseverance!


For Brevity:
1) Reason why QUIC doesn't come up in wireshark, even though it comes up in chrome://net-internal/#quic ?
2) Why does the quic_server need the X-Original-Url pre-header in a file?
3) Is there a better way to stream video using the quic_server, perhaps the caddy server and the quic-go/shaka-player as the client?


I am now able to see QUIC packets in Chrome and UDP packets in wireshark, which brings me to my first question, why is this the case? Why does a normal google website, even just a simple tab in google-chrome display QUIC packets in wireshark and my website doesn't? Did I miss some concept? Or does --origin-toforce-quic-on just forces QUIC in the picture, but not really gets the website hooked up on it?

My second concern, I had to manually add the certificates to the chrome browser. Did I miss something? Because, I think it could've added that itself, couldn't it?

Pushing this topic a bit forward towards the ultimate goal: Streaming via quic_server.

/**  Copied from my first post,
 **
 **  The Dilemma : MPEG-DASH has a set of bitrates and each bitrate has tonnes of segments and other files. Theoretically, if I put everything in the quic_respons_cache_dir with manually
 **  editing each file ( out of the gazillion files ) to add the X-Original-Url, it should work, shouldn't it?
 **
 **  I have done my research though,
 **  This post by Wesley Davison : Makes me wonder do I have to append the header file to each file ( which is tedious for me ) or is there a way, maybe by using my content from Apache
 **  server and use a Shaka Player?
 **/

What are your thoughts on this? Really open to everyone's suggestion.

One essential question, what is the purpose of X-Original-URL preheader? Is it necessary at all? My knowledge is based on this forum page by Microsoft.
If it is a mandatory norm, I feel there has to be a better way for appending a preheader to all video segments, mpd files, index files, icons (I'm guessing) and other misc. files that I have for my website.

Note 1: Looking into using caddy server and the quic-go/shaka-player as the client.
Note 2: Examined the UDP packets from wireshark.
Note 3: Not running from the apache server, gave me a Header missing/ incorrect error, which I figured was because I didn't have the X-Original-URL on every file in every directory. (Unrelated: Added SSL certs to make it a https:// than the old http://)

Summary:
1) Got the QUIC packets,
2) Now onto Streaming via QUIC (quic_server), dilemma: X-Original-URL preheaders,
3) Need some suggestions regarding Server and Client combination.

A side note for the community:
Here's what I've done till now.


1) Building Chromium on Linux: Installed Chromium from here
2) Playing with QUIC: Followed this for quic_server and quic_client
3) Linux Cert Management: Did this after making a folder for <my_website_name>.com in the quic_respons_cache_dir
4) Added the cert files in the browser
5) Edited the /etc/hosts as Gregory mentioned here
6) Pointed the quic_respons_cache_dir to a dummy website, and I was able to run it via QUIC.

Best
Sushant

Sushant Mongia

unread,
Apr 4, 2017, 5:29:28 PM4/4/17
to QUIC Prototype Protocol Discussion group
Hi Jo,

Superb! I got a pretty neat and a verbose log file by adding --log-net-log=/the/path/to/chromelogs.
Thanks for adding this here! Onto analyzing it.
Also I posted a reply to Gregory above. I would really appreciate if you too find some time to look into it and suggest me the proper tools for my path forward.

Best
Sushant

Alexis La Goutte

unread,
Apr 5, 2017, 4:34:40 PM4/5/17
to QUIC Prototype Protocol Discussion group
Hi,

About Wireshark, what (udp) port do you are using ? by default wireshark decode QUIC only on port 443 (no heuristic for found QUIC protocol)

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

Sushant Mongia

unread,
Apr 9, 2017, 4:40:01 PM4/9/17
to QUIC Prototype Protocol Discussion group, alexis....@gmail.com
Hey Alexis,

I am using port 443,
google-chrome \
  --user-data-dir=/tmp/chrome-profile \
  --no-proxy-server \
  --enable-quic \
  --origin-to-force-quic-on=<my_website_name>.com:443 \
  --host-resolver-rules='MAP <my_website_name>.com:443 127.0.0.1:6121' \
  http://<my_website_name>.com/index.html

Should I be editing something in wireshark as well?

Best
Sushant

Alexis La Goutte

unread,
Apr 10, 2017, 2:10:19 AM4/10/17
to Sushant Mongia, QUIC Prototype Protocol Discussion group
Hi,

No,

What release of Wireshark do you are using ? it is recommended to use last git release (2.3.x -> https://www.wireshark.org/download/automated ) when decode QUIC

if always don't work, can you send me (in private ?) your pcap ? and i will look.

Cheers

Gregory Ray

unread,
Apr 25, 2017, 4:00:23 PM4/25/17
to proto...@chromium.org, Sushant Mongia
Hi Sushant,

Sorry for the delay and glad you made progress! The --origin-to-force-quic-on is the real deal, so you should see the udp traffic in wireshark, tcpdump -n udp and chrome://net-internals. Can you check quic section in chrome://net-internals and report back? As far as quic running on google.com, gmail.com, youtube, chrome://newtab, etc; these sites are whitelisted in chrome for testing while quic is still pre-rollout.

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

Quocbao Nguyen

unread,
Apr 26, 2017, 3:09:32 AM4/26/17
to proto...@chromium.org, Sushant Mongia
Hi all,

+ I am a new member of QUIC. I start from building QUIC server in VMware workstation player 12. I got a problem when I built it as follow
build/go_quicError 4 g++: internal compiler error

+ I built the linux virtual machine with configuration: RAM (2GB), Processors (2), Hardisk SCSI (15GB).
+ I used go quic source with comand line:
+ Build source comand line
$GOQUIC_BUILD=Release ./build_libs.sh

Could you please to show me any guideline?

Thank for your attention my question.

Best regards,

--------------------------------------------------------

Bao Quoc NGUYEN

Master 2 Multimédia Networking (MN)
Télécom ParisTech - Université Paris-Saclay

Email: nguy...@telecom-paristech.fr

Gunjan Kumar Choudhary

unread,
Feb 19, 2018, 10:46:57 AM2/19/18
to QUIC Prototype Protocol Discussion group
Dear Gregory,

Can you please tell me where is the code for whitelisting the URL's?
Also can we modify the URL's to list our server URL?

Thanks and Regards,
Gunjan

林秉鉎

unread,
Sep 25, 2019, 10:01:22 AM9/25/19
to QUIC Prototype Protocol Discussion group, alexis....@gmail.com, sushan...@gmail.com
Hi Sushant,

I have the same problem as your case.
In order to make sure that the protocol of packets which transmitted between quic_server and quic_client is Quic.
I captured the packets by wireshark when quic_client downloaded the file from quic_server.
Unfortunately, the protocol of packets which I saw in my wireshark is UDP, not Quic(or gquic).
Are there any problems with my wireshark?
How did you solve this problem before?

Thanks.

Cheer,
Jimmy

Sushant Mongia於 2017年4月9日星期日 UTC+2下午10時40分01秒寫道:

Alexis La Goutte

unread,
Sep 25, 2019, 10:26:27 AM9/25/19
to 林秉鉎, QUIC Prototype Protocol Discussion group, Sushant Mongia
Hi,

last release of gQUIC aren't supported by Wireshark
You working actually to support only IETF-QUIC

Cheers

Emilia Weyulu

unread,
Sep 25, 2019, 11:12:03 AM9/25/19
to QUIC Prototype Protocol Discussion group, alexis....@gmail.com, sushan...@gmail.com
Hi Jimmy,

QUIC uses UDP as the underlying transport protocol so this is ok. If you really want to make sure, open your Wireshark capture file, go to Edit-->Preferences-->Protocols then choose QUIC from the drop down list and enter your server port number. You'll then see QUIC displayed in Wireshark.

林秉鉎

unread,
Sep 26, 2019, 9:01:28 AM9/26/19
to QUIC Prototype Protocol Discussion group, alexis....@gmail.com, sushan...@gmail.com
Dear all,

It's work!! Thank you so much!

Best,
Jimmy

Emilia Weyulu於 2019年9月25日星期三 UTC+2下午5時12分03秒寫道:
Reply all
Reply to author
Forward
0 new messages