Authors: Jeffrey Erman, Vijay Gopalakrishnan, Rittwik Jana, K.K. Ramakrishnan (AT&T Labs – Research)
Presenter: Jeffrey Erman
Motivation and introduction :
The authors compares the performance of HTTP and SPDY -- an open networking protocol developed primarily at Google for transporting web content. After a 4-month measurement-driven analysis, they concluded that SPDY does not outperforms HTTP. According to the authors, this is explained due to the non-harmonic interaction between TCP and the RRC state machine.
Background:
Since HTTP connections are typically short and exchange small objects, TCP does not have sufficient time to utilize the full network capacity. SPDY tries to solve this problem by opening one connection per domain; multiple data streams are multiplexed over this single TCP connection for efficiency.
Measurements and Results:
The authors measure the Page Load Time (PLT) for 20 popular website, both for HTTP and SPDY, and they show that for the majority of the websites there is no significant difference between SPDY and HTTP. This is true only for 3G/4G (while in the case of Wi-Fi SPDY is on average 56% faster than HTTP). They show that, in the case of 3G/4G, HTTP achieves much higher throughput due to the fact that it has more TCP connections, and multiple TCP connections are better than a single TCP connection due to the high fluctuation and multiple retransmissions that occur from how TCP and RCC interact.
Why you should read this paper:
SPDY is a promising new protocols for improving mobile browsing, and this paper shows an in-depth comparison with the existing web-browsing protocol (HTTP). Also, the authors show, in great details, where the greatest part of the delay in web-browsing comes from.
Q&A:
Q1: SPDY is doing a lot of content prioritization in order to reduce the perceived delay. Did you try to compare the user's perceived delay between HTTP and SPDY ?
A: No, but we found that SPDY does not request all objects at once, but goes through multiple rounds.
Q2: How can we design the web-sites so they are more compatible with SPDY?
A: We need to take a fresh look at it. Objects that have some dependency should come together, instead of multiple rounds
Q3: What changes would improve the delay of mobile-pages. Would re-designing web-browsers improve delay?
A: Changes in web-pages and browsers would help, but cross-layer interaction is important and would and changes in the cross-layer interaction between TCP and RRC would bring the most benefits.
Presenter: Jeffrey Erman
Motivation and introduction :
The authors compares the performance of HTTP and SPDY -- an open networking protocol developed primarily at Google for transporting web content. After a 4-month measurement-driven analysis, they concluded that SPDY does not outperforms HTTP. According to the authors, this is explained due to the non-harmonic interaction between TCP and the RRC state machine.
Background:
Since HTTP connections are typically short and exchange small objects, TCP does not have sufficient time to utilize the full network capacity. SPDY tries to solve this problem by opening one connection per domain; multiple data streams are multiplexed over this single TCP connection for efficiency.
Measurements and Results:
The authors measure the Page Load Time (PLT) for 20 popular website, both for HTTP and SPDY, and they show that for the majority of the websites there is no significant difference between SPDY and HTTP. This is true only for 3G/4G (while in the case of Wi-Fi SPDY is on average 56% faster than HTTP). They show that, in the case of 3G/4G, HTTP achieves much higher throughput due to the fact that it has more TCP connections, and multiple TCP connections are better than a single TCP connection due to the high fluctuation and multiple retransmissions that occur from how TCP and RCC interact.
Why you should read this paper:
SPDY is a promising new protocols for improving mobile browsing, and this paper shows an in-depth comparison with the existing web-browsing protocol (HTTP). Also, the authors show, in great details, where the greatest part of the delay in web-browsing comes from.
Q&A:
Q1: SPDY is doing a lot of content prioritization in order to reduce the perceived delay. Did you try to compare the user's perceived delay between HTTP and SPDY ?
A: No, but we found that SPDY does not request all objects at once, but goes through multiple rounds.
Q2: How can we design the web-sites so they are more compatible with SPDY?
A: We need to take a fresh look at it. Objects that have some dependency should come together, instead of multiple rounds
Q3: What changes would improve the delay of mobile-pages. Would re-designing web-browsers improve delay?
A: Changes in web-pages and browsers would help, but cross-layer interaction is important and would and changes in the cross-layer interaction between TCP and RRC would bring the most benefits.
Since HTTP connections are typically short and exchange small objects, TCP does not have sufficient time to utilize the full network capacity. SPDY tries to solve this problem by opening one connection per domain; multiple data streams are multiplexed over this single TCP connection for efficiency. entrust coupons
ReplyDelete