Re: Announcing the TSVAREA session on "Evolution of IETF Transport Protocols" @ IETF-88

[Martin Stiemerling <[e-mail]>]

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:[e-mail]] Sent: Tuesday, October 29, 2013 3:32
>> PM To: Martin Stiemerling; Linda Dunbar; [e-mail] 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