Subject: RE: [rohc] TCP compression

From: "Cho Chia Yuan" <[email-masked]>
Date: Mon, 8 Sep 2003 11:33:07 +0800

Hi Mark,
 
I think it makes sense. Assuming Ethernet-based MTUs would allow some needed optimization for header compression. Although I think you meant more of its utility for sequentially changing fields like sequence number and ack number, here I am trying to add in more advantages of this assumption, not just for these fields, but also for fields like the TCP Window Size option.
 
Working on context replication, I have observed that there are high probabilities of the Window Size field having a value belonging to a set of 'common values'. These common values are related to the Ethernet MTU. For the purpose of context replication, instead of sending the entire 16-bit Window Size field, we can instead (1)define the set of common values encodable with say 3 or 4 bits (2)Encode the field with these 3 to 4 bits in IR-REP packets. (3)Provide fallback to the above compression optimization, i.e. send the field uncompressed if the value do not belong to the 'common values' set. Finally, the definition of the set of 'common values' is in fact non-universal, and is dependent on the direction of flow, i.e. into a (wireless) LAN or coming out of it. 
 
If you are interested, I hope to release the results soon...

Chia Yuan Cho
Student
National University of Singapore

	-----Original Message----- 
	From: West, Mark [mailto:[email-masked]] 
	Sent: Mon 9/8/2003 5:41 AM 
	To: [email-masked] 
	Cc: [email-masked] 
	Subject: [rohc] TCP compression

	Hi all,
	
	Whilst thinking about the TCP profile, I got to wondering about one of the
	tougher problems that we seem to face: what MSS do we assume?
	
	With efforts like the pmtud wg looking to push the path-MTU up, what
	should we go for?  Now, it is clear that the kind of links that have
	really big MTUs are less likely to be an important target for header
	compression (isn't it?!)
	
	I should also be clear that we are categorically *not* talking about TCP
	compression only working for a limited set of MSS's -- we are simply
	talking about the 'sweet spot' for which it will be optimised.
	
	So, I don't see a need to look (much) above the Ethernet MTU..?  (As a
	baseline)
	
	The other issue that occurs is that of retransmissions (which will cause
	jumps in sequence and ack number).  However, intuition and a bit of
	playing with the TFRC equations leads me to suggest that this isn't such a
	big deal:
	
	- if the link has a low loss-rate, then the probability of retransmission
	is correspondingly low and so we don't need to support this with highly
	optimised packet formats (since it is so rare); but
	
	- if the link has a high loss-rate, then the probability of retransmission
	is that much greater, but the window will be correspondingly constrained,
	reducing the range of sequence-space over which we need to be able to
	range.
	
	So, we should support limited sequence-/ack-number jumps relatively
	efficiently and be less worried about larger jumps...
	
	Any thoughts..?
	
	Mark.
	
	_______________________________________________
	Rohc mailing list
	[email-masked]
	https://www1.ietf.org/mailman/listinfo/rohc

h�ɚ�X��X��!r'�~����i����
bz���j)fj��b��?��\