Subject: [NSIS] Any Router Alert Option influence on router performance?

From: "Geib, Ruediger" <[email-masked]>
Date: Wed, 19 Nov 2003 13:00:45 +0100

Dear all,

should anybody of you be aware of measurements 
comparing the influence of processing "router 
alert option" packets on router processing as 
compared to complete absence of these packets, 
I'd appreciate information or a URL. The 
background isn't to prevent such messages. I'm 
interested in learning more about the level 
(if any) where they start to hurt.

Regards, Rüdiger 

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 19 Nov 2003 10:52:05 -0500

> (if any) where they start to hurt.
I don't have specific measurements, but without special-case hardware 
support for the specific function being requested by RA, the performance 
penalty is at least 100x (if you do nothing other than decide to ignore the 
RA) to much more depending on how heavy-weight the actual processing in 
software would be.

I believe this is one big reason why the RSVP aggregation work jumped 
through hoops to avoid the interior routers seing packets with RA set.

Think of them as equivalent to processing a packet addressed specifically 
to the router as opposed to a packet being forwarded. If you would have 
processed the packet locally in software (e.g. you are setting or 
maintaining local control state) using RA doesn't matter at all. The 
serious problem is for routers which DO NOT want to handle the packets.

Dave.
> Regards, Rüdiger

------------------------
David R. Oran
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720
Office: +1 978 264 2048
VoIP: +1 408 571 4576
Email: [email-masked]

---

From: "Michael Welzl" <[email-masked]>
Date: Thu, 20 Nov 2003 19:24:59 +0100

Hi all,

> > (if any) where they start to hurt.

This lack of knowledge has been annoying me for a long
time - so we did measurements. The idea was not to test
specific equipment and not to check its behavior under
stress (that would depend on the brand, I suppose) but
rather to get a general idea of the additional delay
you get by adding ANY option (we used NOP) to a ping in
today's Internet.

> RA) to much more depending on how heavy-weight the actual processing in 

At least 100x to much more??? I wonder where these data come from.

We did two measurements, one in 2001 and one in 2003, and
we traversed 7something000 and approx. 80000 different router
addresses (100 pings each with and without options, a break
of a second in between). Then we did some statistics (applied
weights based on the frequency of occurence of certain router
addresses, variance etc. ... the total result is close to 1%
of additional delay per router (I think it was 0.8% in 2001
and 1% in 2003 or vice versa).

Now this is not representative for "the Internet", of course,
but it's a measurement, so it's at least SOMETHING. I'm working
on the documentation, and I'll make it available as a technical
report via the web as soon as possible (maybe in the next 1 or
2 weeks). For those of you who are greedy for diagrams   :)
here's a VERY VERY VERY VERY preliminary link:
http://www.welzl.at/tmp/option.html
(BTW - it says "2002" on this page, but that's wrong, it was 2001)

The tech-rep will be available from:
http://www.welzl.at/publications/

I believe that there's a tendency to exaggerate about the impact
of Slow Path processing, and this prevents any idea based on
IP options to move forward. On the other hand, judging from your
email address, you should know more details abour option processing
than I do - so I really wonder where these data come from.

Perhaps it's:
difference in delay when looking at processing in a router
vs.
difference in end-to-end delay

The latter - how the overhead relates to the RTT - is more
interesting to me.

Cheers,
Michael

---

From: David Oran <[email-masked]>
Date: Wed, 19 Nov 2003 13:56:29 -0500

The 7xxx is a software forwarding platform. The relative costs are 
obviously much smaller on such a platform.

--On Thursday, November 20, 2003 7:24 PM +0100 Michael Welzl 
<[email-masked]> wrote:

> weights based on the frequency of occurrence of certain router

---

From: "Michael Welzl" <[email-masked]>
Date: Thu, 20 Nov 2003 20:11:12 +0100

7xxx? what is 7xxx?

I guess  that's a misunderstanding because I wrote
"7something000" - I was referring to the number of
router addresses we encountered, which was something
around 76000 or so. Not a brand / product number   :)

Cheers,
Michael

> -----Ursprungliche Nachricht-----
> Von: David Oran [mailto:[email-masked]]
> Gesendet: Mittwoch, 19. November 2003 19:56
> An: Michael Welzl; Geib, Ruediger; [email-masked]
> Betreff: Re: AW: [NSIS] Any Router Alert Option influence on router
> performance?
>
>

---

From: David Oran <[email-masked]>
Date: Wed, 19 Nov 2003 15:38:42 -0500

I read the first number as the type of router and the second number as the 
count of addresses. Sorry for the confusion.

It's still highly relevant if you were testing across routers which do 
software forwarding versus hardware forwarding.

Dave.

--On Thursday, November 20, 2003 8:11 PM +0100 Michael Welzl 
<[email-masked]> wrote:

>> >> RA) to much more depending on how heavy-weight the actual processing
>> >> in software would be.
>> >