[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [rohc] ROHC-TCP: Update and some topics to be discussed
Hi,
I've added a few comments inline on the ROHC-TCP issues not related to
context replication.
One issue that isn't mentioned below is the packet formats themselves
(i.e. the CO packets and the IR-REPLICATE packets). This is the last
major gap in the ROHC-TCP profile - it would be great if we could fill
it in before Vienna, as we'd then have enough to offer a real, working
TCP compression scheme...
For the CO packets, we've made an initial proposal in:
http://www.ietf.org/internet-drafts/draft-price-rohc-tcp-packet-formats-00.t
xt
The draft lists the packet formats in both ROHC-FN form and box notation
form, so we can discuss the formats themselves without worrying about how
they're documented.
For the IR-REPLICATE packets there are currently two proposals - one
using indicator flags in the context replication draft, and one using
indicator codes in:
http://www1.ietf.org/mail-archive/working-groups/rohc/current/msg01523.html
If anyone has comments on either of the above, they would be much
appreciated!
Regards,
Richard
> For the TCP profile to move forward, I have tried to summarize some of
> the topics that require further discussions on the mailing list:
>
> 1) Packet formats for ROHC-TCP, two alternatives:
>
> o Use ROHC-FN, and how to include the packet formats in the
> normative part of the TCP draft, or;
> o Use box or list notation with corresponding normative text
> describing how to encode and decode each field in the header,
> as in RFC-3095.
As well as deciding how to notate the TCP packet formats, we actually
need to design them in the first place ;-)
> 2) Context replication (See the separate draft)
>
> 3) IR/IR-DYN format for ROHC-TCP
>
> The content of Section 5.5.1 is a suggestion from the editor, for
> the purpose of providing grounds for discussions. This section does
> not represent a consensus and the following needs to be addressed:
>
> o Should we use static and dynamic chains, as in 3095?
The chain-based approach might be worth updating for ROHC-TCP, as there
is a lot of scope for compressing the Next Header/Kind fields that
indicate which items are present in the chain.
At a minimum, I think we should replace the Next Header/Kind fields from
the more common TCP options and IP extension headers with shorter
equivalents (e.g. there are 7 common TCP options, so it's enough to send
a 3-bit indicator rather than the entire Kind field in full). More
aggressive compression is possible, but we'd need to discuss whether we
actually need it or not.
> o Compression of TCP options for IR/IR-DYN
We have quite a lot of flexibility here, depending on how aggressive
we want to make the compression. The proposed IR(-DYN) packet formats
in <draft-price-rohc-tcp-packet-formats-00.txt> keep things pretty
simple for the TCP options. We compress the "obvious" fields that can
always be inferred at the decompressor, such as the Length fields in
fixed-length options, but fields with more complex behaviour are always
sent uncompressed.
> o Compression of other TCP fields in IR/IR-DYN:
> - "data offset" is redundant
Definitely worth compressing the Data Offset, as this is guaranteed to
work for all (valid) TCP packets. So we don't need any additional packet
formats...
> - "IP protocol" can be derived from the profile number
Again, we should definitely do this, because it doesn't cost any
extra packet formats.
> - "IP version" -> only two possible values, only one
> bit is required.
Only saves 3 bits, but costs nothing, so let's go for it...
> - "TTL", particularly when compressing over the first hop
Not sure about this one - would be useful for short-lived TCP flows,
but needs at least one additional packet format (to send the TTL in
full, just in case it can't be compressed for whatever reason).
> - "MSN", could be LSB coded
In the IR(-DYN) packets we can't use LSB encoding for the MSN because
we don't have a value in the context. However, if we want more aggressive
compression than just sending the MSN in full, we could potentially
use an encoding method which we call "irregular_padded". It works
like LSB encoding, except that instead of getting the MSBs from the
context, the decompressor assumes that they are 0 instead. This allows
us to compress small values of the MSN down to a few bits right from
the first IR packet.
> 4) Master Sequence Number (MSN)
> o initialization of MSN (0?)
I think that the most flexible solution would be to let the compressor
choose the initial value for the MSN, as it doesn't cause any
interoperability problems to initialise the MSN to a value other than 0.
Of course, the packet formats may influence this decision (e.g. by
encoding small values of the MSN more efficiently than large values).
> o compression of MSN within the packet format (LSB coded?)
In the CO packets we can compress the MSN using LSB encoding (how
many LSBs to send in each packet format is an open issue, which is
discussed further in <draft-price-rohc-tcp-packet-formats-00.txt>).
In the IR(-DYN) packets we can't use LSB encoding, but we can use
"irregular_padded" encoding instead (see above).
> So please feel very welcome to jump into any of these questions. It
> would be good to be capable of moving forward rapidly so that a new
> update can be generated in time for the Vienna meeting. Thanks!
>
> Regards,
>
> /Ghyslain
>
> Ghyslain Pelletier, Dipl. Ing.
> Wireless IP Optimizations
> AWARE - Advanced Wireless Algorithm Research
> Ericsson Research, Corporate Unit
>
> Ericsson AB, Laboratoriegränd 11
> Box 920, S-97128 Luleå, SWEDEN
> Phone : +46 (0) 920 20 24 32
> Mobile: +46 (0) 70 609 27 73
> Ghyslain.Pelletier@epl.ericsson.se
> http://www.ericsson.com
> _______________________________________________
> 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