Max packet size

[Thomas De Keulenaer]

Hi,

I am running tests on the performance of QUIC for video streaming and I noticed the larger protocol overhead of QUIC compared to TCP (both HTTP1.1 and 2).

I also noticed the proto-quic codebase defines:

kDefaultMaxPacketSize = 1350

Can anybody explain why this value was chosen? Why not the maximal packet size of 1452 bytes when using UDP over IP over Ethernet?

Kind regards!

[Ian Swett]

1350 was chosen based on reachability data gathered inside Chrome approximately 4 years ago.  A bit above 1350, an increasing number of users could not send and receive UDP packets.  I don't believe the raw data is public yet, but it will be soon.   Jana would know for sure.

The CPU consumption overhead numbers you post look reasonable to me.  There's an effort to improve that currently, but a lot of time is in the OS UDP send and receive paths, which will take time to improve and roll out.

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

[Thomas De Keulenaer]

Hi,

Thanks for your response.

The graph I posted is not about CPU overhead, but protocol overhead on the wire: 1 - (amount of content bytes)/(amount of bytes received).

On Friday, 7 July 2017 14:18:17 UTC+2, Ian Swett wrote:

1350 was chosen based on reachability data gathered inside Chrome approximately 4 years ago.  A bit above 1350, an increasing number of users could not send and receive UDP packets.  I don't believe the raw data is public yet, but it will be soon.   Jana would know for sure.

The CPU consumption overhead numbers you post look reasonable to me.  There's an effort to improve that currently, but a lot of time is in the OS UDP send and receive paths, which will take time to improve and roll out.

On Fri, Jul 7, 2017 at 4:16 AM, Thomas De Keulenaer <thomas.de...@gmail.com> wrote:

Hi,

I am running tests on the performance of QUIC for video streaming and I noticed the larger protocol overhead of QUIC compared to TCP (both HTTP1.1 and 2).

I also noticed the proto-quic codebase defines:

kDefaultMaxPacketSize = 1350

Can anybody explain why this value was chosen? Why not the maximal packet size of 1452 bytes when using UDP over IP over Ethernet?

Kind regards!

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

[Ian Swett]

Thanks for the clarification.  In your analysis, were you omitting the connection ID?

On Fri, Jul 7, 2017 at 9:13 AM, Thomas De Keulenaer <thomas.de...@gmail.com> wrote:

Hi,

Thanks for your response.

The graph I posted is not about CPU overhead, but protocol overhead on the wire: 1 - (amount of content bytes)/(amount of bytes received).

On Friday, 7 July 2017 14:18:17 UTC+2, Ian Swett wrote:

1350 was chosen based on reachability data gathered inside Chrome approximately 4 years ago.  A bit above 1350, an increasing number of users could not send and receive UDP packets.  I don't believe the raw data is public yet, but it will be soon.   Jana would know for sure.

The CPU consumption overhead numbers you post look reasonable to me.  There's an effort to improve that currently, but a lot of time is in the OS UDP send and receive paths, which will take time to improve and roll out.

On Fri, Jul 7, 2017 at 4:16 AM, Thomas De Keulenaer <thomas.de...@gmail.com> wrote:

Hi,

I am running tests on the performance of QUIC for video streaming and I noticed the larger protocol overhead of QUIC compared to TCP (both HTTP1.1 and 2).

I also noticed the proto-quic codebase defines:

kDefaultMaxPacketSize = 1350

Can anybody explain why this value was chosen? Why not the maximal packet size of 1452 bytes when using UDP over IP over Ethernet?

Kind regards!

--
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.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/d/optout.

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

[Thomas De Keulenaer]

No, I measured the amount of bytes in the content (a video stream) and measured the amount of bytes 'on the wire' with tcpdump (including Ethernet/IP overhead)

[Jana Iyengar]

On Fri, Jul 7, 2017 at 5:17 AM, Ian Swett <ians...@google.com> wrote:

1350 was chosen based on reachability data gathered inside Chrome approximately 4 years ago.  A bit above 1350, an increasing number of users could not send and receive UDP packets.  I don't believe the raw data is public yet, but it will be soon.   Jana would know for sure.

The data is part of our SIGCOMM publication, which will become available in the next month or so here: http://conferences.sigcomm.org/sigcomm/2017/program.html

- jana

[Van Tong]

Hi Thomas De Keulenaer,

I am a newbie about QUIC. Now I want to stream video over QUIC. I have read and built QUIC using https://www.chromium.org/quic/playing-with-quic.

However, I don't know how to apply it in streaming video. Could you show me how to do that?

Thanks for your time and helps,

Van

Vào 15:16:36 UTC+7 Thứ Sáu, ngày 07 tháng 7 năm 2017, Thomas De Keulenaer đã viết:

[张晗]

Hi, I am very interested in QUIC and I am doing some test, Where can we get the data structure of a QUIC packet?

在 2017年7月7日星期五 UTC+8下午8:18:17，Ian Swett写道：

1350 was chosen based on reachability data gathered inside Chrome approximately 4 years ago.  A bit above 1350, an increasing number of users could not send and receive UDP packets.  I don't believe the raw data is public yet, but it will be soon.   Jana would know for sure.

The CPU consumption overhead numbers you post look reasonable to me.  There's an effort to improve that currently, but a lot of time is in the OS UDP send and receive paths, which will take time to improve and roll out.

On Fri, Jul 7, 2017 at 4:16 AM, Thomas De Keulenaer <thomas.de...@gmail.com> wrote:

Hi,

I am running tests on the performance of QUIC for video streaming and I noticed the larger protocol overhead of QUIC compared to TCP (both HTTP1.1 and 2).

I also noticed the proto-quic codebase defines:

kDefaultMaxPacketSize = 1350

Can anybody explain why this value was chosen? Why not the maximal packet size of 1452 bytes when using UDP over IP over Ethernet?

Kind regards!

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