Subject: Re: [pmtud] impact of option processing

From: Simon Leinen <[email-masked]>
Date: Fri, 06 Feb 2004 16:11:36 +0100

Servus Michael,

> The results of our first measurement studies on the
> impact of slow path processing (due to options) are now
> documented in a technical report, which is available from:
> http://www.welzl.at/research/projects/ip-options/index.html

In your abstract, you write

    To make a long story short, the additional delay of our pings was
    10% in a 2002 measurement and 7% in a 2003 measurement when a NOP
    option was included; we encountered approximately 3000 different
    router addresses in both cases.

In your draft, you write that 

  "In IETF and IRTF mailing lists, the impact of option processing has
   been claimed to be immense (e.g., slowing down packets by factor
   100) on several occasions. While this may be true for packet
   processing in a single router, a recent measurement study has shown
   that the impact on end-to-end delay can be much less severe
   [WeRo]."

For operators, comparing option processing delay with the total delay
(which includes link propagation delays) is largely irrelevant.  The
fact that there is an increase at all means that there is a slow path
for packets with options, at least in some (I assume many/most)
routers along your paths.

This means that packets with options consume more forwarding and/or
control-plane resources in routers.  Operators who care about
operation and manageability of their routers will be concerned about
the expected rates of these packets.  For example, the routers we use
in our backbone can process 20-30 million packets per second in the
fast path, but at most a few 100'000s in the slow path.

Given the trends in router technology I'm observing, packets with
options will be rate-limited in order to protect slow path
forwarding/control plane resources.  (At a later stage it is of course
possible that your option will be implemented in the fast path if it
proves useful.)

So you should make sure that (1) you think about keeping the rate of
these probe packets with options as low as possible - for example by
avoiding its use for "tinyflows" - and (2) make sure your mechanism
works well even when probe packets are dropped because of
rate-limiting.
-- 
Simon.

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

---

From: Michael Welzl <[email-masked]>
Date: 09 Feb 2004 13:20:48 +0100

Simon,

Many thanks for your feedback. All I can do is recommend
NOT to use the mechanism for each and every TCP connection
but for special purposes only (e.g. between tunnel endpoints);
it is really an experimental (albeit, as I claim, potentially
useful) proposal.

A source must be aware that there is an increased chance
of experiencing a packet drop when including the option;
this also concurs with our measurements (approx. 44%
of the packets were dropped when an option was included
ONLY - but we do not know who dropped them). I included
a section on packet drops due to options in the update.

Also, some methods to keep the number of packets carrying
these options are specified in the "host operation"
section. I added a prescription to restrict the number
with a percentage of packets generated by a node in order
to ensure scalability.

Best regards,
Michael

-- 
Michael Welzl <[email-masked]>
University of Innsbruck

---

From: Matt Mathis <[email-masked]>
Date: Tue, 24 Feb 2004 11:47:46 -0500 (EST)

Are you going to be at IETF 59?   How would you like this to be covered on the 
agenda?

Thanks,
--MM--

On 28 Jan 2004, Michael Welzl wrote:

> Dear all,
> As I type these lines, a new measurement study is
> ongoing.
> 
> I will include a short paragraph on these results in
> the next update of my draft, "PMTU-Options: Path
> MTU Discovery using Options",
> draft-welzl-pmtud-options-00.txt
> 
> Also, I will include the suggestion from Eddie Kohler
> to add a TTL-based field which will allow the receiver
> to tell if all routers participated or not.
> 
> Best regards,
> Michael
> 
> 

-- 
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
A good plan today is better than a perfect plan tomorrow.
	- Gen Patton

---

From: "Michael Welzl" <[email-masked]>
Date: Tue, 24 Feb 2004 19:13:58 +0100

Dear Matt, dear all,

This is just a little too late   :(

My situation is somewhat difficult when it comes to travel
money; I can only go somewhere if I can show a really good
reason. While this would certainly fall into the category
of a "really good reason", it's too late to get everything
organized.

I would, however, be thankful if you could take it on the
agenda without me; so far, the group has been pretty quiet
about this, and I still believe that it would be reasonable
to take this up as a work group item.

BTW, the latest version of the draft is here:
http://www.ietf.org/internet-drafts/draft-welzl-pmtud-options-01.txt

Best regards,
Michael

> -----Ursprungliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]]Im Auftrag von
> Matt Mathis
> Gesendet: Dienstag, 24. Februar 2004 17:48
> An: Michael Welzl
> Cc: [email-masked]
> Betreff: Re: [pmtud] impact of option processing
> 
>