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