[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:richard.price@roke.co.uk]
Sent: Wednesday, March 12, 2003 10:00 PM
To: 'Lars-Erik Jonsson (EAB)'; 'rohc@ietf.org'
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:Lars-Erik.Jonsson@epl.ericsson.se]
> Sent: Tuesday, March 11, 2003 10:16 PM
> To: Price, Richard; 'rohc@ietf.org'
> 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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc