Yet another UDP pmtud iss, it's different, really

From: Johnson, Chester F
Date: Mon Nov 17 2003 - 01:26:10 EST


List,

This is not the same as the pmtud issues discussed ad-nauseum from 1999
through 2001. It really is different. Trust me, please read on.

Well, it is similar, but with a twist. We are in the middle of deploying
DiffServ compliant QoS throughout our networks and stumbled across an
issue that occurs when we configure our routers to mark the DiffServ
Code Points (DSCP) for UDP traffic (AFS, NFS, other full frame size UDP
traffic).

The problem is that when the marked traffic reaches an IPsec/Ethernet
segment, and the DF bit set to true, an ICMP message is returned to the
transmitting host to say basically "fix your MTU". Since we have changed
the ToS field with DSCP information, the ICMP message no longer matches
anything in the route cache hash. If the ToS field is not "0", it must
match src, dst, and ToS in the cache. Well, we changed one of them and
there can be no such match.

The net result is that the transmitting host sends another 1500 byte
packet and the process repeats itself. Ultimately the data transfer
fails. When we stop DSCP marking, MTU negotiation works just fine, but
we have no QoS.

This kind of match might be great if we use a Linux platform as a
router. It may indeed be useful for higher performance DiffServ routing.
This kind of match requirement for an end-host is problematic. In our
estimation it looks like a bug.

Can anyone out there help sort this out?

Chester Johnson
Network Transport Engineering
Intel Corporation

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/