Subject: RE: [rohc] TCP/IP EPIC profile

From: "Hongbin Liao (Intl Staffing)" <[email-masked]>
Date: Fri, 15 Mar 2002 14:33:32 +0800

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:[email-masked]]
> Sent: Friday, March 15, 2002 6:14 AM
> To: Hongbin Liao (Intl Staffing)
> Cc: Per Synnergren (EPL); [email-masked]
> 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.
>
>

---

From: "West, Mark (ITN)" <[email-masked]>
Date: Fri, 15 Mar 2002 15:07:48 +0000

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

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

-- 
Mark A. West, Consultant Engineer
Roke Manor Research Ltd., Romsey, Hants.  SO51 0ZN
Phone +44 (0)1794 833311   Fax  +44 (0)1794 833433

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