Subject: RE: [rohc] TCP compression profile (described using ROHC-FN)

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Sun, 16 Mar 2003 05:40:16 +0100

Qian,

The updated notation draft has indeed taken a step backwards in
scope and optimization, but it has also taken a few steps forward
in clarity. This is a process we have to go through, and the 
last weeks discussions is an important component in that process.

My interpretation of the TCP example from Richard is thus that it
is just a simple example to show how the notation can be applied.
We will of course have to continue with both the notation work
and the TCP profile specifics, as the TCP profile document does
not even have any packet formats defined yet. The WG has not
come that far yet.

BR
/L-E

> -----Original Message-----
> From: Qian Zhang (MSR) [mailto:[email-masked]]
> Sent: den 14 mars 2003 12:13
> To: Price, Richard; Lars-Erik Jonsson (EAB); [email-masked]
> Subject: RE: [rohc] TCP compression profile (described using ROHC-FN)
> 
> 
> Richard,
> 
> We noticed that there are quite a lot changes for the notation. 
> 1. The probability that original used had been deleted. 
> 2. The global indicator had been replaced by individual field 
> indicator.
> 
> Based on this notation and the sample TCP/IP packet format 
> given in the
> last email, we have several concerns.
> 1. This scheme is quite in-efficient. Since each field needs a bit to
> indicate whether it exists or not, the smallest packet size is 5 bytes
> (just to represent a header without sequence number or acknowledgement
> number change). Moreover, we need another byte for the packet type. 
> 
> 2. The presentation ability is quite weak. For example, it is hard to
> encode the TCP option part. Moreover, for ROHC-RTP case, how to encode
> list type of things? 
> 
> Any comments for that?
> 
> Thanks,
> Qian & Hongbin
> 
> 
> -----Original Message-----
> From: Price, Richard [mailto:[email-masked]] 
> Sent: Wednesday, March 12, 2003 10:00 PM
> To: 'Lars-Erik Jonsson (EAB)'; [email-masked]'
> Subject: RE: [rohc] TCP compression profile (described using ROHC-FN)
> 
> ... and for comparison, the TCP/IP packet formats described using
> ROHC-FN are as follows:
> 
> tcp_ip_encoding       ::=   create_msn
>                             inferred_ip_checksum
>                             ip_header
>                             tcp_header
>                             other_fields
> 
> ip_header             ::=   ip_version
>                             ip_header_length
>                             ip_tos
>                             ip_length
>                             ip_id
>                             ip_reserved
>                             ip_dont_fragment
>                             ip_more_fragments
>                             ip_offset
>                             ip_time_to_live
>                             ip_protocol
>                             ip_checksum
>                             ip_source_address
>                             ip_dest_address
> 
> tcp_header            ::=   tcp_source_port
>                             tcp_dest_port
>                             tcp_seq_ack
>                             tcp_data_offset
>                             tcp_reserved
>                             tcp_ecn
>                             tcp_urg
>                             tcp_ack
>                             tcp_psh
>                             tcp_rsf
>                             tcp_window
>                             tcp_checksum
>                             tcp_urg_pointer
>                             tcp_options
> 
> other_fields          ::=   next_field (MSN)
>                             lsb (3, 0) / irregular (16)
> 
> ip_version            ::=   value (4, 4)
> 
> ip_header_length      ::=   value (4, 5)
> 
> ip_tos                ::=   static / irregular (6)
>                             label (2, ECN)
> 
> ip_length             ::=   inferred_size (16, -48)
> 
> ip_id                 ::=   inferred_offset (16, MSN)
>                             lsb (4, 0) / lsb (8, 0) / irregular (16)
> 
> ip_reserved           ::=   value (1, 0)
> 
> ip_dont_fragment      ::=   static / irregular (1)
> 
> ip_more_fragments     ::=   value (1, 0)
> 
> ip_offset             ::=   value (13, 0)
> 
> ip_time_to_live       ::=   static / irregular (8)
> 
> ip_protocol           ::=   value (8, 6)
> 
> ip_checksum           ::=   skip (16)
> 
> ip_source_address     ::=   static / irregular (32)
> 
> ip_dest_address       ::=   static / irregular (32)
> 
> tcp_source_port       ::=   static / irregular (16)
> 
> tcp_dest_port         ::=   static / irregular (16)
> 
> tcp_seq_ack           ::=   tcp_sack_a / tcp_sack_b /
>                             tcp_sack_c / tcp_sack_d /
>                             tcp_sack_e / tcp_sack_f /
>                             tcp_sack_g / tcp_sack_h /
>                             tcp_sack_i
> 
> tcp_sack_a            ::=   static
>                             static
> 
> tcp_sack_b            ::=   static
>                             lsb (10, 256)
> 
> tcp_sack_c            ::=   lsb (10, 256)
>                             static
> 
> tcp_sack_d            ::=   lsb (10, 256)
>                             lsb (10, 256)
> 
> tcp_sack_e            ::=   static
>                             lsb (14, 4096)
> 
> tcp_sack_f            ::=   lsb (14, 4096)
>                             static
> 
> tcp_sack_g            ::=   static
>                             lsb (18, 65536)
> 
> tcp_sack_h            ::=   lsb (18, 65536)
>                             static
> 
> tcp_sack_i            ::=   irregular (32)
>                             irregular (32)
> 
> tcp_data_offset       ::=   label (4, TCP_Header_Length)
> 
> tcp_reserved          ::=   static / irregular (4)
> 
> tcp_ecn               ::=   ecn_unused / ecn_used
> 
> ecn_unused            ::=   next_field (ECN)
>                             value (2, 0)
>                             value (2, 0)
> 
> ecn_used              ::=   next_field (ECN)
>                             irregular (2)
>                             irregular (2)
> 
> tcp_urg               ::=   label (1, URG_Flag)
> 
> tcp_ack               ::=   static / irregular (1)
> 
> tcp_psh               ::=   irregular (1)
> 
> tcp_rsf               ::=   value (3, 0) / value (3, 4) / 
> value (3, 1) /
> irregular (3)
> 
> tcp_window            ::=   static / lsb (12, 2048) / irregular (16)
> 
> tcp_checksum          ::=   irregular (16)
> 
> tcp_urg_pointer       ::=   next_field (URG_Flag)
>                             urgf_zero / urgf_one
> 
> urgf_zero             ::=   value (1, 0)
>                             static
> 
> urgf_one              ::=   irregular (1)
>                             irregular (16)
> 
> tcp_options           ::=   value (options_length, context_value
> (Index)) /
>                             irregular (options_length)
>                             next_field (TCP_Header_Length)
>                             static / irregular (4)
> 
>         where options_length is (TCP_Header_Length * 32) - 160
> 
> > -----Original Message-----
> > From: Lars-Erik Jonsson (EAB) 
> > [mailto:[email-masked]]
> > Sent: Tuesday, March 11, 2003 10:16 PM
> > To: Price, Richard; [email-masked]'
> > Subject: RE: [rohc] TCP compression profile
> > 
> > 
> > > > Can you send the TCP packet formats you used to the 
> mailing list?
> > > 
> > > No problem.  Would you like them in notated or pictorial form (or
> > > both, for comparison)?
> > > 
> > > If you'd like the packet formats in pictorial form, are 
> the pictures
> > > themselves sufficient or should all of the ancillary information
> > > needed to get "bits on the wire" also be included (e.g. field
> > > dependencies, interpretation intervals for LSB encoding, context
> > > updating properties etc.)?
> > 
> > I think the pictorial form would be ok also without the "rules" for
> how
> > to interpret the bits. Together with the notation form, it 
> would be a
> > good example.
> > 
> > Thanks!
> > /L-E
> > 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Richard Price" <[email-masked]>
Date: Sun, 16 Mar 2003 08:50:31 -0800

> in clarity.

Hi,

There seems to be some confusion between the notation draft itself,
and the implementation that we just published!

The updated notation draft contains no technical changes from the old
draft, so its scope and optimization remain exactly the same.  However,
the implementation that we made available to the WG only includes a
subset of the features documented in the notation draft - enough to
demonstrate the notation in action, but not enough for an "optimally"
efficient set of compressed TCP packet formats.

> not even have any packet formats defined yet. The WG has not

Exactly.  The example TCP packet formats only use encoding methods
supported by our published implementation, so there's plenty of room
for improvement.

> > number change). Moreover, we need another byte for the packet type.

We can generate more efficient indicator bits by taking into account the
probability that each field encoding will be used.  This feature is
available
in the current notation draft (Section 6.4.3), but we haven't used it in the
TCP packet formats just yet because it's not supported in the
implementation.

> > encode the TCP option part. Moreover, for ROHC-RTP case, how to encode

Both of the above can be compressed using the "list" encoding method
(Section 6.5.1 of the notation draft).  We'll use this to compress the TCP
options as soon as we've added it to the published implementation.

Regards,

Richard