Subject: RE: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Thu, 1 Feb 2007 17:30:55 +0100

>> Anyway, I will get back with a text proposal shortly.

Alternative 1:
==============
Proposal
- Remove last paragraph of sections 6.4.1 and 6.4.2
- Add in section 3.2 before the last paragraph:
 
   Header compression algorithms generally make the implicit assumption
   that any checksum present in the protocol header it processes is
   consistent with the fields protected by the checksum. In particular,
   for the IPv4 header and for the MINE header, the purpose of the
   checksum is to protect individual hops from processing a corrupted
   header. As a consequence, it is assumed that a compressor will not
   process a corrupted header. Otherwise, because these checksums are
   compressed away and recalculated in the decompressor
   [REF inferred_ipv4_checksum()][REF inferred_mine_checksum()],
   transparency cannot be guaranteed for a header with an inconsistent
   checksum. 

Alternative 2:
==============
Proposal (section 6.4.1):
- Replace last paragraph of section 6.4.1 with:

   The purpose of the IPv4 header checksum is to protect individual
   hops from processing a corrupted header. This encoding method
   implicitely assumes that the compressor will not process a
   corrupted header. Otherwise, this encoding method cannot guarantee
   that the checksum as recomputed by the decompressor will be bitwise
   identical to its original value before compression.

- Replace two last paragraphs of section 6.4.2 with:

   The motivations abnd the assumptions for inferring this checksum
   are similar to the ones explained above in Section 6.4.1.

-----Original Message-----
From: Ghyslain Pelletier (LU/EAB)
[mailto:[email-masked]] 
Sent: den 31 januari 2007 15:05
To: Magnus Westerlund (KI/EAB); [email-masked]
Cc: Carl Knutsson; West, Mark; Carsten Bormann; [email-masked]; Lars-Erik
Jonsson
Subject: RE: [rohc] RE: AD comments on draft-ietf-rohc-tcp-15

Hej Magnus,

This could be an acceptable alternative from my perspective, to
formulate it as to what it is an assumption of the compression profile,
somewhere in section 3. However, I have always been under the impression
that that was implicit from the specifications of IPv4 no matter what.

Anyway, I will get back with a text proposal shortly.

///Ghyslain

Magnus Westerlund wrote:
> [email-masked] skrev:
>> Magnus, Kristofer,
>> 
>> I totally disagree with changing the current wording.
>> 
>> I totally agree with Carsten and Mark opinion previously expressed
>> on this thread, which arguments were very much in-line with my
>> initial answer. 
>> 
>> I think that we should not specify anything in our profiles that
>> would lead to a compressor discarding a packet. Once again, it is
>> not the responsability of header compression to police other
>> protocol/stack behavior. 
>> 
>> Wrt to the "transparency issue", header compression has always used
>> the assumption that erroneous IP checksums would never reach the
>> compressor, and Carsten in addition pointed out that this has been
>> discussed and agreed long time ago. Furthermore, as Carsten pointed
>> out, IPv6 folks did not even include a cheksum in the IPv6 header
>> for a reason. 
>> 
>> Personally, I would remove the sentence entirely, and I think that
>> would follow all other other RoHC specs very nicely.
>> 
>> Regards,
>> 
>> ///Ghyslain
>> 
> 
> If it always has been an assumption that erroneous headers will not
> reach the compressor, can you please point out where in the current
> set of document that assumption is documented?
> 
> In case it is not documented can we please document it. I am fine with
> removing the normative sentence as long as the assumption is correctly
> documented and the possible effects of not fulfilling this assumption.
> 
>  From my perspective I think it is important that you document the
> cases when transparency is only fulfilled as certain assumptions are
> meet. 
> 
> Cheers
> 
> Magnus Westerlund
> 
> IETF Transport Area Director & TSVWG Chair
> ----------------------------------------------------------------------
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> ----------------------------------------------------------------------

_______________________________________________
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: Magnus Westerlund <[email-masked]>
Date: Fri, 02 Feb 2007 11:36:59 +0100

>>> Anyway, I will get back with a text proposal shortly.

If the two inffered header checksums are the only two cases when this 
can occur I personally would prefer alternative 2.

Cheers

Magnus Westerlund

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Fri, 2 Feb 2007 15:56:10 +0100

Magnus,

I have updated the RoHC-TCP draft in the CVS after your comments:
http://www.dmn.tzi.org/cgi-bin/cvsweb.cgi/fn/
I will submit an updated version.

///Ghyslain

Magnus Westerlund wrote:
>>    Header compression algorithms generally make the implicit
>>    assumption that any checksum present in the protocol header it
>>    processes is consistent with the fields protected by the
>>    checksum. In particular, for the IPv4 header and for the MINE
>>    header, the purpose of the checksum is to protect individual hops
>>    from processing a corrupted header. As a consequence, it is
>>    assumed that a compressor will not process a corrupted header.
>>    Otherwise, because these checksums are compressed away and
>>    recalculated in the decompressor [REF
>>    inferred_ipv4_checksum()][REF inferred_mine_checksum()],
>>    that the checksum as recomputed by the decompressor will be
>>    bitwise identical to its original value before compression.
>>