[e2e] "PMTUD using options" draft

[Sneha Kumar Kasera]

I had looked at this paper (and enjoyed reading it) some time ago and 
this is what I had  observed then.

The proposed scheme aims to find the delay in generating ICMP Time 
Exceeded messages (used in traceroute and pathchar) in the slow path of 
a router. ICMP Time Exceeded delay is obtained by taking the median of 
the difference of the slow path delay and an estimated fast path delay 
(instead of min filtering). The paper finds that that this median delay 
in generating ICMP Time Exceeded message is in the sub millisecond range 
and concludes that tools that use ICMP Time Exceeded messages can be 
accurately used to measure network behavior.

In my opinion, saying that 50 percentile of the ICMP Time Exceeded 
messages were generated in less than a millisecond is not good enough. 
In fact I would be more interested in the higher percentiles or at least 
the variability from the median. I think the variability would capture 
the queuing delay in the slow path. Unless it is shown that variability 
from the median is low or a very high percentile of ICMP Time Exceeded 
messages were generated in less than a millisecond, I don't think one 
could conclude that queuing delays in the fast path can be measured from 
slow path data.

Sneha


Stefan Savage wrote:

>FWIW, there's a nice little paper that Ramesh Govindan and Vern Paxson did
>trying to measure slow-path effects for ttl exceeded generation.
>
>http://www.icir.org/vern/papers/fsd-pam-02.pdf
> 
>The high-bit is that they indeed find that this isn't a common issue on the
>modern Internet.
>
>- Stefan
>-----Original Message-----
>From: end2end-interest-admin at postel.org
>[mailto:end2end-interest-admin at postel.org] On Behalf Of RJ Atkinson
>Sent: Thursday, February 12, 2004 8:35 AM
>To: Michael Welzl
>Cc: end2end-interest at postel.org
>Subject: Re: [e2e] "PMTUD using options" draft
>
>
>On Feb 12, 2004, at 10:49, Michael Welzl wrote:
>  
>
>>Some things may really make sense as an IP option, but
>>you usually can't propose them in the IETF because a
>>number of people tell you that this is unrealistic
>>because of slow path processing, which makes everything
>>at least 700 times slower.
>>    
>>
>
>I agree that people say this.  Such people generally are
>not people who have experience building modern routers.
>The main reason I mentioned this on-list here is to try
>to spread the word that the common-belief is myth not
>reality (at least for a while now).
>
>  
>
>>No proof, no numbers, no measurements.
>>    
>>
>
>That is a common frustration with IETF.  I like the
>idea of experimental computing science very much.
>
>  
>
>>The idea was just to change that. If I know that IP
>>options typically lead to an approximate additional
>>delay of about 7%, I may be able to judge wheter a
>>proposal based on IP options makes sense or not.
>>
>>I mean, I can't measure everything ... for instance,
>>what if I flood a router with packets carrying options?
>>Will the result be the same?
>>    
>>
>
>	If one has a hardware-based router that is designed to
>perform packet processing at wire-rate, one would expect
>that the flooding would not matter (unless/until the affected
>interface itself filled up).
>
>Cheers,
>
>Ran
>
>
>  
>