Re: [rohc] TCP/IP EPIC profile

["West, Mark (ITN)" <[e-mail]>]

Hi Hongbin,

Some more attempts at answers!

Cheers,

Mark.

> 
>     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.
> 


Sorry!  I had not noticed that NOP was missing from the option LIST 
encoding...

NOP can be trivially handled by a VALUE encoding which handles the 
'type' (nothing else is necessary), following the pattern of the 'end of 
options' encoding:

    tcp-option-nop = VALUE(8,1,100%) ; type

(but, see later...)


>     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?
> 


In terms of picking the right count for the maximum number of NOPs, I 
don't know the answer - other than making an educated guess.

However, having thought some more about this, I'm not sure that we 
actually need to support [many] NOPs in the LIST encoding.  Since one of 
the common uses is to word-align other options, we can handle the NOPs 
within the option encoding.

To use timestamps as an example, we could re-write the encoding used in 
the LIST as:

    tcp-timestamp-co = padded-ts(50%) | unpadded-ts(50%)

    padded-ts = base-ts-option
                tcp-nop-option
                tcp-nop-option

    unpadded-ts = base-ts-option

    tcp-nop-option = VALUE(8,0,100%)

This effectively adds a flag to the TS option encoding to indicate 
whether padding is present or not.

Alternatively, an encoding similar to the PAD method that is introduced 
in the example SCTP profile that we've started looking at 
(http://search.ietf.org/internet-drafts/draft-west-sctp-epic-00.txt) 
could be used, though this might be considered excessive.

In general, the meta-data is expected to be quite stable, and so should 
not need to be sent repeatedly.  This is obviously true for lengthy 
connections.  However, it might be worth looking at further with regard 
to the impact on short-lived flows.

>  
> 
>  
> 
> Thanks!
> 
> Hongbin L.
> 
> 15/03/2002
> 
>  


-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone [phone]   Fax  [phone]

(Yes, I do know that my disclaimer is in an attachment.  And, no, I 
didn't ask for it to be that way)