[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[rohc] RFCs 3095, 3241 - feedback CID encoding - apparent contradiction



Referring to RFC 3095, 5.2.2, page 46:

   The large CID, if present, is encoded according to section 4.5.6.
   CID information in feedback data indicates the CID of the packet
   stream for which feedback is sent.  Note that the LARGE_CIDS
   parameter that controls whether a large CID is present is taken from
   the channel state of the receiving compressor's channel, NOT from
   that of the channel carrying the feedback.

There's a problem with this.
How can the decompressor (which wants to send a feedback packet) know
what the channel state of the peer compressor is?

I imagine that most of the time, you could make a pretty good guess by
looking at the LARGE-CIDS parameter (RFC 3095, 5.1.1, page 39) of the
channel on which the last packet from that compressor arrived.

But in RFC 3241 (ROHC/PPP), page 2, it says:

   A PPP ROHC sender may send packets in either small-CID or large-CID
   format at any time, i.e., the LARGE_CIDS parameter from [RFC3095] is
   not used.  Any PPP ROHC receiver MUST be able to process both small-
   CID and large-CID ROHC packets, therefore no negotiation of this
   function is required.

The compressor has the following options for use of the 0x0003 and 0x0005
PPP protocols in ROHC/PPP:

1.	Send all ROHC forward data packets with CID <= 15
	with PPP protocol = 0x0003, therefore with small-CID encoding.
	(This is not an unreasonable choice.)

2.	Send all ROHC forward data packets with CID <= 15
	with PPP protocol = 0x0005, therefore with large-CID encoding.
	(This is also not unreasonable, because then the software
	doesn't need to bother with small-CID encoding ever - for forward pkts.)

3.	Send ROHC forward data packet with CID <= 15 with mixed choices of
	PPP protocol 0x0003 and 0x0005, therefore with mixed CID encodings.
	(This is explicitly permitted by RFC 3241.)

So now I want to send an ACK packet to a compressor which has chosen
option 3 - mixed PPP protocols.
How do I encode the CID for the feedback message?
This is important because the compressor has to decode the CID according to
the (undefined) LARGE_CIDS parameter in order to make sense of those
bytes it receives. The result in case of misinterpretation could be garbage,
except that it could make a guess on the basis of the leading bits
of the first octet of the feedback message.
But then if the compressor is _expected_ to use the leading bits to
guess the CID encoding, then why bother to state that in RFC 3095,
5.2.2, page 46 that the feedback message encoding must be chosen
acording to the compressor's channel state?

===================================================
In RFC 3241, part 4, page 7, there's this:

   Note that this implies that all CIDs within one ROHC packet MUST be
   of the same size as indicated by the Data Link Layer Protocol field,
   either small or large.  In particular, embedded feedback MUST have a
   CID of the same size as indicated by the Protocol field value.  For
   piggybacking feedback, a compressor must be able to control the
   feedback CID size used by the associated decompressor, ensure that
   all CIDs are of the same size, and indicate this size with the
   appropriate Protocol Field value.

This seems to resolve the issue, but it directly contradicts RFC 3095.
It means that a compressor which receives feedback messages must
refer to the PPP DL layer protocol field to decode the CID,
whereas for general ROHC in RFC 3095, the compressor receiving feedback
messages must decode them according to the well-defined LARGE_CIDS
paramter for the channel to which the compressor is attached.

My conclusion is:
RFCs 3095 and 3241 are in contradiction.
The encoding and decoding of feedback messages is different in
general ROHC compared with ROHC/PPP.
This would imply that ROHC encoder/decoder software written for
ROHC/PPP would be erroneous for non-PPP ROHC.

At the very least, there should have been a note in RFC 3241, page 7,
stating that the CID-encoding rules for feedback in ROHC/PPP
contradict and supersede the CID encoding rules for ROHC in
RFC 3095, 5.2.2, page 46.

===================================================
Am I right about this?
Or have I missed something here?

Cheers,
Alan Kennington.  
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc