Hannes Tschofenig writes:
[...]
- denial of service issues with the router alert option: it is true
that router alert option processing is slower than packets which do
not have the router alert option set. however, i am not sure whether
this is truely a big issue based on the most recent information i
saw (see http://www.welzl.at/research/projects/ip-options/).
This study compares the delay experienced by packets with IP options
to the delay experienced by packets without IP options, for a wide
variety of Internet paths. It observes that on average, IP options
introduce between 7% and 26% (for different sets of paths at different
times) of additional delay. The article says that "In any case, the
additional delay is clearly an order of magnitude smaller than the
RTT."
To some people, this may suggest that option processing overhead isn't
a problem in today's Internet. I don't buy this at all.
The problem is this: A large part of the measured baseline delay is
due to propagation times (length of links/speed of light in fiber) and
thus mostly independent of whether IP Options are used or not.
If, as I suspect, the part of the delay that is actually due to
per-hop processing is small (for the baseline no-options case), then a
7%-26% increase of the *total* delay could mean an orders-of-magnitude
increase in per-hop processing overhead when IP options are used.
To illustrate this, here are the results of Michael's "extended ping"
test over a cross-town path with five GbE hops, sorted by RTT:
NONE 64 bytes from 130.59.35.42: seq=10007, ttl=62, rtt=0.171 ms
NONE 64 bytes from 130.59.35.42: seq=10009, ttl=62, rtt=0.172 ms
NONE 64 bytes from 130.59.35.42: seq=10005, ttl=62, rtt=0.178 ms
NONE 64 bytes from 130.59.35.42: seq=10001, ttl=62, rtt=0.202 ms
NONE 64 bytes from 130.59.35.42: seq=10000, ttl=62, rtt=0.209 ms
NONE 64 bytes from 130.59.35.42: seq=10008, ttl=62, rtt=0.211 ms
NONE 64 bytes from 130.59.35.42: seq=10003, ttl=62, rtt=0.216 ms
NONE 64 bytes from 130.59.35.42: seq=10006, ttl=62, rtt=0.220 ms
NONE 64 bytes from 130.59.35.42: seq=10004, ttl=62, rtt=0.225 ms
NONE 64 bytes from 130.59.35.42: seq=10002, ttl=62, rtt=0.233 ms
NOP 64 bytes from 130.59.35.42: seq=20005, ttl=62, rtt=0.735 ms
NOP 64 bytes from 130.59.35.42: seq=20003, ttl=62, rtt=0.769 ms
NOP 64 bytes from 130.59.35.42: seq=20006, ttl=62, rtt=0.775 ms
NOP 64 bytes from 130.59.35.42: seq=20000, ttl=62, rtt=0.803 ms
NOP 64 bytes from 130.59.35.42: seq=20008, ttl=62, rtt=0.803 ms
NOP 64 bytes from 130.59.35.42: seq=20004, ttl=62, rtt=0.816 ms
NOP 64 bytes from 130.59.35.42: seq=20002, ttl=62, rtt=0.885 ms
NOP 64 bytes from 130.59.35.42: seq=20009, ttl=62, rtt=1.749 ms
NOP 64 bytes from 130.59.35.42: seq=20001, ttl=62, rtt=3.456 ms
NOP 64 bytes from 130.59.35.42: seq=20007, ttl=62, rtt=4.288 ms
The optionless packets have an RTT between 171 and 233 microseconds
(other traffic on the path may explain the variance). The packets
with NOP IP options have an RTT between 735 and 4288 microseconds.
This strongly suggests that IP options cause slow-path processing on
our routers.
Most operators won't worry about the additional delay incurred by
packets that use IP options. But they WILL worry about the total
processing overhead in their routers when there are many such packets,
because slow-path resources are usually shared with the control plane,
and operators just hate it when control of the network is impacted by
user traffic.
I can see a few possible outcomes when IP options become more common:
1.) Routers implement option processing in the fast path
- this will be expensive and/or take time if the fast path is "in
hardware", e.g. mostly based on ASIC/FPGA/CAMs. I think it will
be hard to motivate this.
2.) Router vendors implement rate-limits for packets with
(router-alerting) IP Options. The rate-limiting must be done in
the fast path, while options processing can remain in the slow
path. Maybe the rate-limits can be differentiated by
option/extension header type, maybe not.
3.) Operators configure their routers to ignore IP Options.
4.) Operators configure their routers to drop packets with IP Options.
Regards,
--
Simon.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf