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

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Jan 2007 18:17:38 +0100

Hi,

First sorry for the long delay in getting this review done.

First, thanks for a great document. However there are some very minor 
things that needs to be fixed before going forward.

Section 5.2.2, The reference to 5.2.3.1, should be to 5.2.4.1 as I 
understand it.

Question, shouldn't the "should"s in feedback logic in Section 5.3.1.3 
and 5.3.1.4 be in capitalized?

Section 6.4.1: Last paragraph:
   "The compressor MAY use the header checksum to validate the
    correctness of the header before compressing it, to avoid compressing
    a corrupted header."

I wonder how this can be a MAY. To me it should be a requirement to do 
if you are performing HC and infeering the checksum in the compressor. 
Changing the packet from one with non-matching checksum to one with a 
matching one seems pretty serious.

Section 8.1:
You provide the TCP sequence number with bits assuming that the MTU will 
be 1500 bytes. Can you please explain what happens in cases when the 
path MTU is larger than 1500 bytes, like 4k or 9k. I do understand that 
this is so far not that likely for systems that needs header 
compression. However I do like to understand what affect this will have.

Section 8.2: Please change all the occurances of "tos_tc" to "dscp".

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Mon, 29 Jan 2007 16:38:45 +0100

Magnus,

Thanks for your review.

> First sorry for the long delay in getting this review done.

All things being relative with respect to when this wg started working
on a profile for TCP, I would not worry too much over this ; )

See my comments inline.

Let me know if these are satisfactory, also let me know if you need an
updated draft to be submitted in order to move the draft forward once
we've agreed on this.

///Ghyslain

> Section 5.2.2, The reference to 5.2.3.1, should be to 5.2.4.1 as I

Agreed.
 
> and 5.3.1.4 be in capitalized?

No, I think that small "should" is ok in these sections. This is because
this is related to something that is very much up to the implementation,
but mainly because these shoulds are based on "if context damage is
assumed" -- which is itself only loosely defined on purpose.

>     correctness of the header before compressing it, to avoid
>     compressing a corrupted header."
> 

IMHO I think a MAY here is in fact the only alternative that is proper.

My understanding is that making this statement anything else than a MAY
would go beyond the scope of a header compression protocol -- there is
no requirement to sanity check the protocols that it compresses. 

While I agree that header compression has the requirement to not produce
a decompressed header that differs from the original header
(transparency), I do not think it is a requirement of the header
compression protocol to generally verify the validity of the semantics
of the protocol it compresses for any field, not even for the IP
checksum.

Therefore, I do not consider this particular issue to be in fact related
to transparency, or to impact it in any way. This situation would occur
with a packet that is already faulty.

The compressor MAY, however, make an additional verification as
suggested in the draft, because the regeneration of the checksum is
somewhat of a special case as you pointed out.

In addition, this type of statement cannot be policed in an
implementation, so there is little point in making this a "MUST" anyway.
Furthermore, considering that todays L2 are rather strong against
residual errors, and that IP stacks that generate erroneous IP checksum
are also not the norm, this  situation is not expected to occur often
enough to make it a case. I am also not too keen in making this extra
processing anything else than purely optional, as it would have
otherwise to be applied to every packet to catch a potential error with
very low probability of occurring.

Finally, the TCP checksum is always present to protect TCP (the pseudo
header covers the IP source and destination addresses), so would this
situation occur the packet will anyway be discarded in the receiving end
host.

Note finally that there is not a potential failure of the protocol
(RoHC-TCP) itself associated with this, i.e. Contexts will not go out of
synch and there will be no propagation of this error, if it occurs at
all.

The sentence that you refer to is there only to highlight that this
additional verification is possible, the only other alternative from my
perspective (if you deem it to be a problem) would be to remove the
sentence.

I hope that we can either agree to leave it as it is (with MAY), or
alternatively to simply remove it altogether (previous RoHC wg specs
don't have such a statement).

> Section 8.1:
> You provide the TCP sequence number with bits assuming that the MTU
> will be 1500 bytes. Can you please explain what happens in cases when
> the path MTU is larger than 1500 bytes, like 4k or 9k. I do
> understand that this is so far not that likely for systems that needs
> header compression. However I do like to understand what affect this
> will have. 

The compressor would have to select a larger packet format, e.g.
co_common.

> Section 8.2: Please change all the occurances of "tos_tc" to "dscp".

Agreed.

---

From: "West, Mark" <[email-masked]>
Date: Mon, 29 Jan 2007 21:51:41 -0000

[Mark] and to put this in context, a co_common packet in a bulk-transfer environment (in the data-transfer direction) might be something like 10 - 12 octets.  With a 4kbyte packet, this is 0.3% overhead (compared with 1% for no compression).  The bigger cost is in the 'ack' direction, since all of an 'ack' is overhead.  However, where we have a link with such a large MTU, we are effectively making some assumptions about the degree of asymmetry and the overall link capacity.  But I don't really see that as a problem...

[Mark] I also support Ghyslain's statement on the issue of the compressor verifying checksums.

Cheers,

Mark.

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 30 Jan 2007 18:12:24 +0100

Hi,

I am not agreeing here. To me it seems that allowing the usage of 
inferred IPv4 Header checksum without verifying the checksum prior to 
compression allows for non-transparent header compression. Sure the IP 
header fields that may be incorrect are limited to the ones outside of 
the TCP pseudo header. However that includes a number of important 
fields, including DSCP. The reason I think it is a transparency issue is 
that a erroneous IP header arrive at the compressor. If the checksum 
would be checked the compressor would discard the packet. The compressor 
compresses it using the inferred IPv4 checksum. The decompressor 
reconstructs the same header as previous with the exception that the 
IPv4 header checksum now matches the reconstructed header. Thus 
incomming IPv4 Header is different from outgoing. Transparency failure.
Thus I still think this should be a MUST to ensure the transparency of 
the compression.

cheers

Magnus Westerlund

---

From: "West, Mark" <[email-masked]>
Date: Tue, 30 Jan 2007 22:52:58 -0000

But, playing devil's advocate, does the responsibility for checking and discarding packets not lie with the receiving interface?  That is, the compressor should never see a packet with an erroneous IP checksum.  In which case, this text seems redundant?  Honestly, I'm not sure any more.  But if this isn't in RFC 3095 (or any of the subsequent other compression profiles, such as UDP-lite, IP-only, ...), then why have we only just spotted it?!

(And I haven't checked the mailing list archive, but I've just had a definite sense of deja vu about this discussion...)

Cheers,

Mark.

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: Tue 30/01/2007 17:12
To: Ghyslain Pelletier (LU/EAB)
Cc: [email-masked]; Lars-Erik Jonsson; Kristofer Sandlund (LU/EAB); West, Mark
Subject: Re: AD comments on draft-ietf-rohc-tcp-15

Hi,

cheers

Magnus Westerlund

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jan 2007 00:28:15 +0100

On Jan 30 2007, at 23:52, West, Mark wrote:

> (And I haven't checked the mailing list archive, but I've just had  
> a definite sense of deja vu about this discussion...)

We sure spent a lot of time on this set of issues on a certain May  
29th in 2000...

We since had a long-running WG consensus that IPv4 checksums are  
worthless.
(Somehow, the parents of IPv6 must have arrived at the same  
conclusion six years earlier.)

Mark is right that IPv4 packets with header checksum errors should  
never reach a compressor, as the checksum should have been checked on  
the incoming interface.  (Do routers still do this these days?)  Only  
certain exotic "bridge-mode" configurations would be an exception to  
this.
And, of course, bit errors in memory (where the packet will have  
lived after checksumming its header) will not be caught.
October 27, 1980 notwithstanding*), I wouldn't care.

Gruesse, Carsten

*) RFC 789, if this reference is opaque to you.

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 31 Jan 2007 08:32:19 +0100

Hi,

although it has been ignored in the past ROHC specifications, I agree 
with Magnus point. But as Mark stated, this will _usually_ be
checked by the receiving interface. Maybe we can re-phrase the text a
bit
so that we don't say that the _compressor_ has to verify the checksum 
and instead write that:
   "...MUST NOT compress packets with an invalid IPv4 checksum"
That way, most deployments won't have to do anything as the compressor
will
know that the checksum has already been verified by another layer and we
don't risk breaking compression transparency.

/Kristofer

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Jan 2007 09:04:32 +0100

> don't risk breaking compression transparency.

This sounds like a fine rewording to me. I would also suggest that you 
qualify this with explicitly stating the assumption that the receiving 
interface of the device the compressor is running on will perform this 
check.

Cheers

Magnus Westerlund

---

From: "Kristofer Sandlund \(LU/EAB\)" <[email-masked]>
Date: Wed, 31 Jan 2007 10:07:19 +0100

Carl Knutsson <mailto:[email-masked]> wrote on den 31 januari 2007
09:44 :

>>> although it has been ignored in the past ROHC specifications, I
>>> agree with Magnus point. But as Mark stated, this will _usually_ be
>>> checked by the receiving interface. Maybe we can re-phrase the text
>>> a bit so that we don't say that the _compressor_ has to verify the
>>>    checksum and instead write that: "...MUST NOT compress packets
>>> with an invalid IPv4 checksum" That way, most deployments won't
>>> have to do anything as the compressor will know that the checksum
>>> has already been verified by another layer and we don't risk
>>> breaking compression transparency. 
>>> 
> 
> Before you go ahead with this change, I just want to remind you that a
> packet with an incorrect IPv4 checksum can be compressed transparently
> with the uncompressed profile.
> 
> /Calle

But we're only discussing the ROHC-TCP profile here, so this change
should
not affect the ability of the uncompressed profile to be used.
I guess we _could_ write "..MUST not be compressed using this profile",
but
I don't think that really adds anything, so I'd prefer not to do that.

/Kristofer

> 
> 
>>> /Kristofer
>> 
>> This sounds like a fine rewording to me. I would also suggest that
>> you qualify this with explicitly stating the assumption that the
>> receiving interface of the device the compressor is running on will
>> perform this check. 
>> 
>> Cheers
>> 
>> Magnus Westerlund
>>

---

From: Carl Knutsson <[email-masked]>
Date: Wed, 31 Jan 2007 09:44:10 +0100

Hi,

/Calle

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Jan 2007 10:03:47 +0100

> with the uncompressed profile.

The issue is still that you can't use inferred IPv4 checksum unless you 
know that it would be correct. Thus you would need to perform the 
checksum calculation to know this. And in case you have a failure of the 
checksum you should drop the packet. As I see it there are no need to 
compress a packet with an erroneous IP header. To me it seems that the 
fact of this case is that you can't use inferred checksum unless you 
know that checksum prior to compression matches the header.

Cheers

Magnus Westerlund

---

From: [email-masked]
Date: Wed, 31 Jan 2007 14:36:19 +0100

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

---

From: [email-masked]
Date: Wed, 31 Jan 2007 14:37:44 +0100

Magnus, Kristofer,

Regards,

///Ghyslain

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 31 Jan 2007 14:47:52 +0100

> all other other RoHC specs very nicely.

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

---

From: "Ghyslain Pelletier \(LU/EAB\)" <[email-masked]>
Date: Wed, 31 Jan 2007 15:05:22 +0100

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:
>> 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
>> 
> 
> reach the compressor, can you please point out where in the current
> set of document that assumption is documented?
> 
>  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
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 31 Jan 2007 15:02:37 +0100

On Jan 31 2007, at 14:47, Magnus Westerlund wrote:

> you please point out where in the current set of document that  
> assumption is documented?

RFC 3095 says:

    Header Checksum

       The header checksum protects individual hops from processing a
       corrupted header. When almost all IP header information is
       compressed away, there is no point in having this additional
       checksum; instead it can be regenerated at the decompressor side.
       The field is therefore classified as INFERRED.

Well, it's rather implicit.  This paragraph only makes sense if you  
read the first sentence as "the previous hop will already have  
discarded a packet with a bad checksum"; the rest then talks about  
the lack of need for protecting the next hop (the one with the  
compressed header).

But I think I agree with Magnus' stipulation; this all has been  
rather implicit in the documents (while it was more explicit in our  
minds).

Gruesse, Carsten

---

From: "Lars-Erik Jonsson" <[email-masked]>
Date: Wed, 31 Jan 2007 15:41:00 +0100

>       The field is therefore classified as INFERRED.

Which is based on what RFC 1144 says, i.e.:
   "But then the header checksum (bytes 10 and 11), which protects
    individual hops from processing a corrupted IP header, is essentially
    the only part of the IP header being sent.  It seems rather silly to
    protect the transmission of information that isn't being transmitted.
    So, the receiver can check the header checksum when the header
    is actually sent (i.e., in an uncompressed datagram) but, for
    compressed datagrams, regenerate it locally at the same time the
    rest of the IP header is being regenerated."

In both cases it is implictly assumed that the IP checksum is only
about THIS hop anyway, so its value at the compression point is
irrelevant if the checksum is excluded by the compression scheme.
There is no transparency issue with the IP checksum field, as it is
a per-hop field.

I'll wait for Ghyslain's concrete text proposal before I say anything more.

/L-E