RE: [rohc] TCP/IP EPIC profile

["Qian Zhang" <[e-mail]>]

Hi Per,
 
Please see my comments inline...
 
Regards,
Qian
 

 

 

-----Original Message-----
From: Per Synnergren (EPL) [mailto:[e-mail]] 
Sent: Thursday, March 14, 2002 3:38 PM
To: '[e-mail]'
Subject: RE: [rohc] TCP/IP EPIC profile

 

Hi all, 

 

A question "out of the blue"...

 

Hongbin Liao wrote:

	1. whether can TCP/IP EPIC profile correctly describe the
behavior of TCP? Or, whether EPIC is powerful enough to describe the
complicated behavior of TCP/IP?
	
	    In EPIC, fields are assumed to be independent from each
other. Once each field's behaviors are described well, the whole
protocol's behaviors are also well-studied. However, in practice, fields
in a protocol may not behave independently completely from each other.
There may be some connections (or causality) among several fields. For
example, most TCP traffics only contain one-way traffic (WWW browsing,
FTP downloading, etc.), i.e., only SEQ changes on the forward path (from
server to client) and only ACK changes on the backward path (from client
to server). The ACK on the forward path and SEQ on the backward path
remain constant. However, in TCP/IP EPIC profile, the probabilities for
SEQ and ACK are specified seperately:

	It is obvious that knowledge about "TCP inter-field correlation"
could be useful in order to increase the performance of the header
compression. 

	[Qian] Since there exist the "inter-field correlation" in TCP
protocol (actually in other protocols, such as SCTP and RTP, there also
such correlation), we need to represent those correlations accurately
for compression efficiency.

	Has anyone heard of/or performed thorough studies of the
cross-correlation between TCP-fields?  

	[Qian]  Interesting! As we discussed before in the mailing list,
there are several TCP options that will only occur in SYN packet. Of
course, that is an example for cross-correlation. For example, as
defined in [RFC2018], the Sack-Permitted Option "may be sent in a SYN by
a TCP that has been extended to receive (and presumably process) the
SACK option once the connection has opened. It MUST NOT be sent on
non-SYN segments.". 
	 
	As Mark mentioned in his email, more detail analysis about TCP
behavior can be found in
http://search.ietf.org/internet-drafts/draft-west-tcpip-field-behavior-0
1.txt
<http://search.ietf.org/internet-drafts/draft-west-tcpip-field-behavior-
01.txt>  and ROHC-TCP draft. We are refining this now, any comments are
welcome.