Re: [rohc] comment on ROHC-TCP

[Kuntal Chowdhury <kuntal@iqmail.net>]

Hi Mark,
when I re-read the text in section 3.3 I notice that it briefly points out the 
distinction between HTTP1.0 and HTTP1.1. I agree with you that for persistence 
to work, the server must support HTTP1.1 and it must be willing to keep the TCP 
connection open for multiple HTTP transactions. Actually this behavior of the 
application is controlled by the "Connection header".
e.g.:
Connection: Keep-Alive.
Connection: Close.

After receiving the first Connection header, the application in the MS pretty 
much knows whether the TCP socket is a persistent one or not. this knowledge can 
be leveraged in some way to distinguish which TCP connection is really short 
lived and which ones are not.

Thoughts?

-Kuntal



West, Mark (ITN) wrote:
> Hi Kuntal,
>
> Thanks for this comment (which relates to the behaviour as well as to the interpretation of this in the main compression draft).  I've got a bunch of updates for the TCP behavior (thanks to a number of very useful comments from various people) -- and this has reminded me to post a proposed update!
>
> Broadly speaking, I agree with your distinction.  However, it raises a couple of interesting points.  For example, it is perhaps worth pointing out that 'short-lived' doesn't necessarily relate to the duration for which the connection is open, but rather the volume of data that is transferred.  So, for example, the FTP control connection could be regarded as short-lived (at leat compared with the data connection)?!  (I don't know if that necessarily makes an isolated short-lived connection less rare, though...)
>
> In principle, your comments about HTTP/1.0 vs HTTP/1.1 make sense.  But if I understand it correctly, the benefits of HTTP/1.1 rely upon agreement between the browser and server and the appropriate configuration of both (certainly of the server)?  You can certainly still have multiple connections to the server with HTTP/1.1.  I'd certainly appreciate input on this application-layer behaviour, as it impacts on the transport.
>
> Anyway, I'll propose some updated (behaviour) text in the next few days.
>
> Cheers,
>
> Mark.
>
>
>
>
> > -----Original Message-----
> > From: Kuntal Chowdhury [mailto:kuntal@iqmail.net]
> > Sent: 21 January 2003 20:38
> > To: rohc@ietf.org
> > Subject: [rohc] comment on ROHC-TCP
> >
> >
> > Hello folks,
> > I think we need to separate the issues between a single short 
> > lived TCP 
> > connection (rare event) from multiple (near-)simultaneous short lived
> > TCP connections. The reason being, the scenario of single short lived 
> > TCP connection applies to both HTTP1.0 and 1.1, however the 
> > scenario of 
> > multiple short lived (near-)simultaneous TCP connections may be a 
> > problem with HTTP1.0 only (HTTP1.1 solves the problem with 
> > persistence 
> > and pipelining as default behavior). Therefore I suggest, we split 
> > section 3.3 to discuss single short lived and multiple 
> > (near-)simultaneous short lived TCP connections separately.
> >
> > Thoughts?
> >
> > -Kuntal
> >
> > _______________________________________________
> > Rohc mailing list
> > Rohc@ietf.org
> > https://www1.ietf.org/mailman/listinfo/rohc
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > Registered Office: Roke Manor Research Ltd, Siemens House, Oldbury, Bracknell, 
> > Berkshire. RG12 8FZ
> >
> > The information contained in this e-mail and any attachments is confidential to Roke 
> >
> > Manor Research Ltd and must not be passed to any third party without permission. This 
> >
> > communication is for information only and shall not create or change any contractual 
> >
> > relationship.

_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc