RE: [rohc] TCP/IP EPIC profile

["Hongbin Liao (Intl Staffing)" <[e-mail]>]

Hi, Mark
    There are more issues here:
    1. Processing of TCP No-Operation may miss in the EPIC-LITE TCP/IP Profile since this option is a single octet of option-kind (no option-length). It can not be handled using 'tcp-generic-co' which read option-length to determine how many octets should be uncompressed.
    2. As you said, the 'presence' and 'order' meta-field sizes have to be increased to N bits and N*ceiling(log2(N-1)) bits respectively, N is the number of methods in LIST encoding. For example, as recommended in several RFCs and DRAFTs in IETF working group, SACK & Timestamp both will be widely used in future Internet, there may exist 4 TCP No-Operation options for work-alignment:
    NOOP, NOOP, SACK, NOOP, NOOP, Timestamp
To support at leasst 4 occurances of TCP No-Op option, the number of methods in tcp-options-dyn/tcp-options-co have to be increased to 12 (8 original one + 4 tcp-noop methods). The presence and order are enlarged to 12 bits and 48 bits, totally 60 bits (at least in IR/IR-DYN, CO will be discussed later) regardless of how many TCP options are included in one TCP/IP. Furhtermore, the 60 bits donesn't count the compressed bits for options themselves, such as SACK, Timestamp and etc. I'm not sure whether it is a efficient way to compressed TCP options. Since, at most, TCP options can only occupy 192 bits ((64-40)*8), the compressed TCP options' meta fields (60 bits) alone will count about 30% of the uncompressed TCP options. If other options, such MSS, may introduce more NOOP options, how to determine the maximum occurances of TCP No-Operation option?
 
 
Thanks!
Hongbin L.
15/03/2002
 
 



> -----Original Message-----
> From: West, Mark (ITN) [mailto:[e-mail]]
> Sent: Friday, March 15, 2002 6:14 AM
> To: Hongbin Liao (Intl Staffing)
> Cc: Per Synnergren (EPL); [e-mail]
> Subject: Re: [rohc] TCP/IP EPIC profile
>
>
>
>
> Hongbin Liao (Intl Staffing) wrote:
>
> > Hi, Mark
> >
> >     I'am refining the EPIC TCP/IP profile these days. I am not so
> > clear
> > about the TCP options processing in the profile. The
> question is how
> > EPIC handle multi-occurances TCP NOP options since we found, for at
> > least two popular TCP/IP stack implementations, there are
> at least 3~4,
> > or more, occurances of TCP NOP options in one TCP/IP packet when
> > Timestamp and/or SACK options are used. Would u give some comments
> > and/or examples on it?
> >
>
>
> Add more NOP options to the LIST encoding.  And increase the
> 'presence'
> and 'order' meta-field sizes to accommodate the extra data required.
>
> Cheers,
>
> Mark.
>
>