Subject: [rohc] TCP compression 'open issues'

From: "West, Mark" <[email-masked]>
Date: Mon, 28 Jul 2003 00:37:58 +0100 (GMT Daylight Time)

Fellow ROHC-ers,

For those of you who couldn't make the IETF or, alternatively, found ospf
more compelling and so missed the 'open issues' presentation, here is a
summary of the issues with suggested answers [for most cases].  It's a bit
terse, so if you don't understand anything, give me a shout.

Acks or nacks would be appreciated.  (especially if the nack has a 'reason
code' and a suggested fix/answer ;-)

- ip version will be '4' or '6'
  -> encode it in a single bit

- ipv4 ip id can be 'byte-swapped'
  -> we should account for this...

- random ipv4 ip id behaviour
  -> we should treat this as a special case (as does 3095)

- 'always 0' ipv4 ip id behaviour
  -> we should treat this as a special case (as the IP only profile draft)

- TCP 'psh' flag
  -> don't bother trying to compress it

- should it be posisble to 'replicate' the DSCP
  -> yes, but this requires static/irregular behaviour in the IR-replicate

- should it be posisble to 'replicate' TTL
  -> yes (see also DSCP, above)

- should it be possible to replicate ipv4 ip id
  -> no, but it should be possible to replicate the behaviour
     (random, irregular, counting, nbo flag)

- what about the reserved bits?
  -> we should handle these
     since we don't know how they'll be used in the future,
     suggest that they are either all always carried, or
     never carried

- does 'df' need to be supported in compressed packets
  -> no

- can we exploit common values for TTL
  -> not a lot of point, because this would rely upon the
     compressor being co-located with the end-point and the
     saving is not great (especially as TTL could be replicated)

- ECN
  -> should be supported (the bits either always sent or never)
  -> little point in trying to compress the ECN bits
     (we are assuming ECN nonces)

- IP headers (how many should be compressed)
  -> as many as are there

- is it worth having simpler formats for ipv6
  -> yes

- does tcp change the use of extension headers in any way
  -> no

- should we assume frequent changes to the TCP window
  -> yes, but common values might be established

- TCP urgent flag / pointer
  -> URG flag of 0 means URP is ignored
     expect it be 0 / unchanging
  -> URG is used infrequently; not worth much effort for special handling

- TCP Sequence / Acknowledgement numbers
  - Behaviour is structured -> to what extent can/should we exploit this
  - Many cases where packets may frequently have the same size
  - How robust (in terms of packet loss) does ROHC-TCP need to be?
    -> suggest a small number (e.g. 2)
  - What (max) size should be assumed for the TCP MSS?
    -> Ethernet (1460 bytes)?

- is it worth treating 'SYN-only' options specially to optimise
initialisation?
  -> yes

- is it worth handling options that come and go (e.g. SACK)?
  -> yes

- is it worth compressing the timestamp option?
  -> yes, but what clock resolutions are commonly used?

- is it worth linking the TS option to the ack flag?
  -> no, because ACK is only unset on the initial SYN packet

- are there options other than SACK, TS, WSCALE, MSS that should be
compressed?
  -> no, but 'generic' options should be compressed more efficiently
     if they remain static

- Master Sequence Number (MSN) - do you need it in every packet?
  -> maybe!  (can only ack packets with MSN,
              other fields might depend on it)

- Is a 3-bit CRC enough to protect TCP compression?
  -> Warning: large IPR discussion required at this point!
  -> However, generally, we need to think about issues relating to the
     TCP checksum (which is carried end-to-end) and the need for
     additional protection.  It is clear that 'damage propagation' for
     TCP is really bad news...

Curiously, the IPR discussion seems to have gone quiet.  But, never fear,
I will follow up on this topic shortly!

Cheers,

Mark.

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc