SHUTR Protocol (Suppressed Headers for Uplink Traffic Reduction)

Question

Hello forum, I was trying to gather some info about Qualcomm's SHUTR protocol, and this is the only thing google threw back:

"SHUTR is a HTTP protocol extension designed to reduce the size of HTTP request headers sent by a mobile user agent. SHUTR speeds up page downloads and reduces network data traffic, overall improving the mobile Web experience on Snapdragon processor-based devices."

Does anyone know how this works? I assume they would be trying to eliminate redundant Header bytes in HTTP POSTS, like in "Request URI", "User Agent", "Cookies" or "Referer". This would allow me to send more POSTS

Which makes a lot of sense, especially when combined with small CWND on the user side that prevent the server from achieving a full BDP (the more TCP ACKs I can piggy back on HTTP Posts, the better for the server to get into a "warm" TCP state closer to the RWIN). Am I correct?

Also, what type of compression would they use?

Best regards

Accepted Answer

The only things that google returns for SHUTR are press releases and a few sentences about the way it might work. So, bad luck, no information available.

I assume they would be trying to eliminate redundant Header bytes in HTTP POSTS, like in "Request URI", "User Agent", "Cookies" or "Referer". This would allow me to send more POSTS

I agree, but it will be for all requests not just POST requests.

Am I correct?

I agree. The 'savings' for TCP are certainly one effect of SHUTR. However, unless we find a detailed description, we can only speculate!

Also, what type of compression would they use?

I don't know what they are doing, but I don't believe it's 'compression', as the call the method: Suppressed Headers for Uplink Traffic Reduction.

I can (again) only speculate, but here is how I would do it, to reduce the amount of HTTP request headers.

define a set of possible values for the typical headers in HTTP requests (User-Agent, Content-Type for POST, Connection:, Host:, etc.)
Then encode those headers in a 'compressed' way

Example

Instead of sending:

GET /test.html HTTP/1.1
Cookie: test=abc123; path=/; domain=.domain.com;
User-agent: MobileDevice/1.0 SnapDragon QC4 4.2.1
Host: test.domain.com
Connection: Keep-Alive

You would send this for the first time:

GET /test.html HTTP/1.1
X-SHUTR: 1.0:0x2732372,0x83787483,0x87939929,0x74837843
Cookie: test=abc123; path=/; domain=.domain.com;
User-agent: MobileDevice/1.0 SnapDragon QC4 4.2.1
Host: test.domain.com
Connection: Keep-Alive

Where the SHUTR 'values' are placeholders for the headers, in the order they appear.

0x2732372 = placeholder for the string: "Cookie: test=abc123; path=/; domain=.domain.com;"
0x83787483 = placeholder for the string: "User-agent: MobileDevice/1.0 SnapDragon QC4 4.2.1"

etc.

Both the client and the server build a 'string-table' and are then able to use the placeholders instead of the strings.

The second time if you need to send the same headers again, you would just send the SHUTR values (placeholders) for those strings.

GET /test2.html HTTP/1.1
X-SHUTR: 1.0:0x2732372,0x83787483,0x87939929,0x74837843

UPDATE: While I was editing my post a few minutes ago, I thought: If there is no general information available, maybe they have a patent or something.

Bingo!

http://www.google.com/patents/WO2011066585A1

I did not fully read the patent text, but from the keywords I've seen, it looks like I 're-invented' their method ;-))

<rant> If that is the case (and I believe so), I question the whole patent system once again. Is something worth a patent, that can be 'invented' by a guy in a Q&A site within 5 minutes, while he answers a question? No way!!! Reason: Because that's how others have solved a similar problem before, like byte caching in WAN accelerators (that's why I came up with that method rather fast). It's not O.K. (in my eyes) to receive a patent for a technique that others have used before, just because you apply it in a slightly modified way for a certain protocol! </rant>

Regards
Kurt