[Top] [All Lists]

Re: PMTU issues due to TOS field manipulation (for DSCP)

To: Julian Anastasov <ja@xxxxxx>
Subject: Re: PMTU issues due to TOS field manipulation (for DSCP)
From: "David S. Miller" <davem@xxxxxxxxxx>
Date: Wed, 10 Dec 2003 15:20:39 -0800
Cc: niv@xxxxxxxxxx, ak@xxxxxxx, ruddk@xxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx, chester.f.johnson@xxxxxxxxx
In-reply-to: <Pine.LNX.4.44.0312110103280.1519-100000@xxxxxxxxxxxx>
References: <20031210145149.2bd89e9b.davem@xxxxxxxxxx> <Pine.LNX.4.44.0312110103280.1519-100000@xxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
On Thu, 11 Dec 2003 01:15:06 +0200 (EET)
Julian Anastasov <ja@xxxxxx> wrote:

> It seems, there are no many users of OIF!=0 but if TOS is
> used as routing key we can see up to 8 entries with different
> TOS for same SADDR,DADDR. Of course, it looks difficult to
> walk 8 rows just to check all TOS variants, the common case
> is to see only one TOS value used. That is why I propose
> to eliminate the TOS as hash key and to walk one row. At first
> look, the risk of DoS is same, thanks to the random value.

This is not my understanding at all.

Consider the case where we generate routing cache entries for
all 8 TOS values.  Currently we'll likely get a O(1) lookup
for any one of those entries.

Your proposal guarentees that all such entries will land to the
same hash chain, since TOS is not an input for the hash any longer.
Therefore the lookup in my example case will be O(8).

And instead of just eating the complexity at ICMP PMTU handling
time, we eat the complexity at every routing cache lookup.

I really don't think we can consider this.

<Prev in Thread] Current Thread [Next in Thread>