On 10/29/2013 09:58 PM, Linda Dunbar wrote:
Here is my naive thinking of some improvement to be done at the
transport layer for HTTP. I say naïve because it could be totally not
feasible.
More and more flows need to go through some additional functions (or
treatment) based on HTTP header (e.g. HTTP request or reply). But the
HTTP header is not fixed in the payload. There could be multiple
HTTP headers in one packet, or one HTTP message being carried by
multiple packets. Therefore, it requires expensive DPI to filter
packets with certain HTTP characteristics.
It would make life easier for network equipment if the TCP header has
a few bits to indicate the characteristics of HTTP message being
carried. E.g. offset to the HTTP header, the number of HTTP message
in the packet, etc.
I don't see any need to make TCP specific to HTTP.
Martin
Linda
-----Original Message----- From: Wesley Eddy
[mailto:[email protected]] Sent: Tuesday, October 29, 2013 3:32
PM To: Martin Stiemerling; Linda Dunbar; [email protected] Subject:
Re: Announcing the TSVAREA session on "Evolution of IETF Transport
Protocols" @ IETF-88
On 10/29/2013 4:18 PM, Martin Stiemerling wrote:
Hi Linda,
We have a full talk about QUIC which is not exactly HTTP but
might
get
us some taste of the direction of HTTP.
However, if there are specific things to discuss, I am more than
open
to
discuss them.
If there's anything to discuss about HTTP, it would relate to its
needs from a transport protocol, as was done a bit at IETF87 and on
mailing lists afterwards.
HTTP itself isn't a transport protocol. People run over it in
order to get through middleboxes and want to view it that way, but
there are still real transport protocols underneath it (TCP, QUIC,
etc).
-- Wes Eddy MTI Systems
