Re: [TERNLI] Forwarding corrupt packets

Michael Welzl <michael.welzl@uibk.ac.at> Mon, 04 September 2006 07:59 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK9MQ-0004RO-1h; Mon, 04 Sep 2006 03:59:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GK9MO-0004Pk-0f for ternli@ietf.org; Mon, 04 Sep 2006 03:59:12 -0400
Received: from gibson.q2s.ntnu.no ([129.241.205.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GK9MN-0000xT-E4 for ternli@ietf.org; Mon, 04 Sep 2006 03:59:11 -0400
Received: from dhcp103.q2s.ntnu.no (dhcp103.q2s.ntnu.no [129.241.205.103]) by gibson.q2s.ntnu.no (Postfix) with ESMTP id 66CD52DD342; Mon, 4 Sep 2006 09:59:05 +0200 (CEST)
Subject: Re: [TERNLI] Forwarding corrupt packets
From: Michael Welzl <michael.welzl@uibk.ac.at>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <44F8780D.9060503@isi.edu>
References: <1157097623.3192.34.camel@lap10-c703.uibk.ac.at> <44F83E74.1080603@isi.edu> <1157121036.3192.148.camel@lap10-c703.uibk.ac.at> <44F84AD5.7070307@isi.edu> <1157131227.3192.220.camel@lap10-c703.uibk.ac.at> <44F8780D.9060503@isi.edu>
Content-Type: text/plain
Organization: University of Innsbruck
Message-Id: <1157356740.3197.57.camel@lap10-c703.uibk.ac.at>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.2 (1.2.2-4)
Date: 04 Sep 2006 09:59:01 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc
Cc: ternli@ietf.org
X-BeenThere: ternli@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Transport-Enhancing Refinements to the Network Layer Interface <ternli.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ternli>
List-Post: <mailto:ternli@ietf.org>
List-Help: <mailto:ternli-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ternli>, <mailto:ternli-request@ietf.org?subject=subscribe>
Errors-To: ternli-bounces@ietf.org

> The question is the impact of the bad packet.
> 
> If the transport checks things and silently discards bad packets, then
> the only harm is bandwidth, and I figured this wouldn't be substantial
> (since errors are presumably somewhat random).

Agreed.


> If the transport reacts to corrupt packets - as would be the case with
> UDP-lite and some configs of DCCP - that would be very bad. The
> difference is whether we're talking about corrupted data and corrupted
> headers; corrupt data isn't too bad (that's what UDP-lite and DCCP are
> designed for). Corrupt headers are VERY bad to forward.

I still don't get it - no matter how you use them, the
reaction of DCCP and UDP-Lite would always be to silently
discard a packet if the transport header is wrong, so
no harm is being done (except for the potential waste of
bandwidth you mention above, but we agree that this isn't
substantial).


> >> The link/net ought not look at the transport layer. If it does, it's
> >> because it needs to access info at that layer (for app-layer
> >> forwarding). In that case, it's necessary to drop the packet because
> >> forwarding isn't possible.
> > 
> > I'd agree that having it look at the transport layer is not
> > clean design, but that's what we ended up with in the UDP-Lite RFC:
> > 
> >    For a link that supports
> >    partial error detection, the Checksum Coverage field in the UDP-Lite
> >    header MAY be used as a hint of where errors do not need to be
> >    detected.  Lower layers MUST use a strong error detection mechanism
> >    [RFC-3819] to detect at least errors that occur in the sensitive part
> >    of the packet, and discard damaged packets.  The sensitive part
> >    consists of the octets between the first octet of the IP header and
> >    the last octet identified by the Checksum Coverage field.  The
> >    sensitive part would thus be treated in exactly the same way as for a
> >    UDP packet.
> 
> The link isn't looking at the net layer for forwarding here; it's
> looking only for an optimization to detect errors over a subset of the
> packet.
> 
> For UDP-lite, when the link error is detected (above), the checksum
> coverage field could be wrong, which means that it's inappropriate to
> use that information to limit link error coverage, and that the packet
> MUST be discarded (see 'discard' above).

I see that this is in the specification, but I question that
it would have to be so strict (could also be a SHOULD in my
opinion). The reason is that the checksum coverage field is
itself covered by UDP-Lite's checksum in any case, so the
harm is again just a waste of bandwidth.


> > If you're going to do this, it might be better to selectively
> > enable/disable it.
> 
> I disagree; once link protection is provided as noted above and the
> UDP-lite checksum fails, there is NO utility in forwarding the corrupted
> packet anywhere. So you forward it to the endpoint... to which port? The
> port is corrupt, so you can't know you're sending it the right place.

I agree that UDP-lite detection by links as above eliminates
any need for such explicit signaling. I however question that
this is clean design - now links should detect UDP-Lite, look
at the checksum coverage field, then they should also detect
DCCP and forward corrupt data if it makes sense according
to the DCCP header. What's next?

This is why I'd prefer an explicit message. This being said,
there are of course also issues with it - for instance, if
the link layer should only do this for the specific flow
which requests it, it must again look at the IP header to
classify flows. This is probably not much "cleaner" than the
scenario I criticize here. Then again, a link could just
forward any corrupt data for a while upon reception of such
a message, and that single state would have to be refreshed.

I'm guessing that you won't like that - such behavior
of course requires all the receivers to be able to
"survive" the reception of corrupt data. I think
that this should be the case anyway, though - that's
why we have transport checksums.


> > What you're saying seems to mean that a link layer must not
> > forward corrupt data unless it has a means to check whether
> > at least its header is correct.
> 
> Yes- that's how I read section 4 of the UDP-lite doc, quoted above, and
> repeated in specific here:
> 
> ----
> Lower layers MUST use a strong error detection mechanism [RFC-3819] to
> detect at least errors that occur in the sensitive part of the packet,
> and discard damaged packets.
> ----

I say that this is too strict, based on our previous
discussion, where you (convincingly) argued that it was
okay for a link to forward IPv6 packets with errors.

Now you refer to a much stricter specification - so let's
use TCP over IPV6 as a reference, not UDP-Lite.


> > I don't know any link layer
> > technology that can do this - so you're saying that partial
> > and separate checksums as in UDP-Lite and DCCP should not
> > exist, or only be there for the case where you have a link
> > layer that can restrict its checksum to the link layer header.
> 
> That's exactly how I read section 4 above.

Hm, right, both the UDP-Lite and DCCP spec are as strict
as that about this issue, requiring this (in my opinion
ugly) method of communication between the transport and
link layers anyway, perhaps making it pointless to add
additional explicit communication...


> > Even that might be a nice feature for a new link layer
> > technology in my opinion, but in any case you're
> > contradicting existing language in the UDP-Lite and
> > DCCP RFCs, where it is assumed that link layers can
> > in fact forward corrupt data.
> 
> Yup. Further in sec 4 of the same doc:
> ---
>    Link layers that do not support partial error detection suitable for
>    UDP-Lite, as described above, MUST detect errors in the entire UDP-
>    Lite packet, and MUST discard damaged packets [RFC-3819].
> ---

*sigh* ... I just forgot how strict all that text was.
I wish it wasn't.


> > Let's pick DCCP as an example protocol. If C throttles its
> > connection because of corruption, it means that the Data
> > Checksum option is in place - which will detect a failure
> > in the header and therefore drop the packet. This feature
> > ("option" - one has to be careful what one calls a feature
> > in DCCP) is there to prevent exactly this type of problem
> > from occurring.
> 
> That assumes:
> 
> 	a) partial coverage of the packet by a strong link
> 	layer
> 
> 	b) correct checksum of the packet at the DCCP-partial
> 	layer
> 
> I.e., IMO, the same requirements as for UDP-lite (I haven't checked
> DCCP, which is a longer spec, but I'll assume it has similar
> requirements, or -should- ;-)

This would also work without a), and that's exactly why
I think that the specifications (indeed, both of them
have these statements you quote here) are too strict in
this aspect.

But that's just the way they are, so I guess there's
no point in debating them right now.


> > Again, you seem to contradict your original statement from 2005.
> > If you changed your mind, why?
> 
> See above; header vs. data. I've never presumed that forwarding or
> signalling based on a corrupt header is appropriate.

Well yes, you said it's appropriate to forward an IPv6 packet
with a broken IPv6 header, or at least that it doesn't cause
harm. This type of forwarding just isn't happening for DCCP
and UDP-Lite because their specs are so strict about this matter.

Cheers,
Michael