Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

From: "Fan, Peng" <[email-masked]>
Date: Tue, 6 Aug 2013 11:54:21 +0800

Hi Ramki,

Thanks for commenting. Let me clarify your statement first. Are you saying that the reason why ICMP is given a different treatment by routers is to prevent DDoS attacks?

There may be different reasons for which ICMP is treated specially, for example routers may give high priority in processing and forwarding to packets of network control protocols, e.g. ICMP, routing protocols, etc. This section is explaining that if ICMP packets and service packets to be measured experience different treatments, then using ICMP to measurement packet loss is not advised. A basic requirement for using ICMP (and other active measurement approaches) is to let probing traffic and service traffic have the same drop probability, though it is usually difficult to guarantee this.

Regards,
Peng

> -----邮件原件-----
> 发件人: ramki Krishnan [mailto:[email-masked]]
> 发送时间: 2013年8月6日 0:43
> 收件人: Fan Peng; [email-masked]
> 主题: RE: [OPSAWG] Fwd: New Version Notification for
> draft-fan-opsawg-packet-loss-01.txt
> 
> Sorry, missed the section -- I am including it. My comments are on Section 5 a.
> 
> >> If this method is to be used on a router, one is advised to make sure
> >> that the ICMP packets experience the same  forwarding and discarding
> courses as the service traffic (of  which the packet loss rate is to be measured)
> does, otherwise the measurement will not make sense.
> 
> I wouldn’t quite agree with this. The reason it is done so today is to prevent ping
> flood type of DDoS attacks
> 
> Thanks,
> Ramki
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ramki Krishnan
> Sent: Sunday, August 04, 2013 4:23 PM
> To: Fan Peng; [email-masked]
> Subject: Re: [OPSAWG] Fwd: New Version Notification for
> draft-fan-opsawg-packet-loss-01.txt
> 
> >> If this method is to be used on a router, one is
>  advised to make sure that the ICMP packets experience the same  forwarding
> and discarding courses as the service traffic (of  which the packet loss rate is to
> be measured) does, otherwise the measurement will not make sense.
> 
> I wouldn’t quite agree with this. The reason it is done so today is to prevent ping
> flood type of DDoS attacks.
> 
> Thanks,
> Ramki
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fan Peng
> Sent: Friday, July 05, 2013 7:56 AM
> To: [email-masked]
> Subject: [OPSAWG] Fwd: New Version Notification for
> draft-fan-opsawg-packet-loss-01.txt
> 
> Dear all,
> 
> We have updated a complete revision to the I-D regarding packet loss
> measurement , and would like to get feedback from you:
> 
> IP Packet Loss Rate Measurement Testing and Problem Statement
> http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01
> 
> The document aims to review methods for packet loss rate measurement and
> problems with them, and provide some guidelines when performing the
> measurement. The document is based on operational experience and needs
> especially when doing performance monitoring on the interconnecting link
> between two providers' networks. We also hope we can find after the discussion
> a measurement scheme that is convenient enough and provides consistent
> results.
> 
> Any comment would be appreciated. Thank you!
> 
> Regards,
> Peng
> 
> 
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]]
> 发送时间: 2013年7月5日 21:44
> 收件人: Peng Fan; Mach Chen; Lu Huang; Mach (Guoyi) Chen; Nagendra Kumar
> 主题: New Version Notification for draft-fan-opsawg-packet-loss-01.txt
> 
> 
> A new version of I-D, draft-fan-opsawg-packet-loss-01.txt
> has been successfully submitted by Peng Fan and posted to the IETF repository.
> 
> Filename:	 draft-fan-opsawg-packet-loss
> Revision:	 01
> Title:		 IP Packet Loss Rate Measurement Testing and Problem
> Statement
> Creation date:	 2013-07-05
> Group:		 Individual Submission
> Number of pages: 15
> URL:
> http://www.ietf.org/internet-drafts/draft-fan-opsawg-packet-loss-01.txt
> Status:          http://datatracker.ietf.org/doc/draft-fan-opsawg-packet-loss
> Htmlized:        http://tools.ietf.org/html/draft-fan-opsawg-packet-loss-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-fan-opsawg-packet-loss-01
> 
> Abstract:
>    This document describes common methods for measuring packet loss rate
>    and their effectiveness.  Issues encountered when using the methods
>    and necessary considerations are also discussed and recommended.
> 
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: ramki Krishnan <[email-masked]>
Date: Mon, 5 Aug 2013 21:07:40 -0700

Hi Peng,

What I am saying is that DDoS attack prevention is one of the primary reasons. With that in mind, it may not be prudent for ICMP packets to experience the same forwarding and discarding courses (or drop probability) as the service traffic.

Thanks,
Ramki

-----Original Message-----
From: Fan, Peng [mailto:[email-masked]] 
Sent: Monday, August 05, 2013 8:54 PM
To: ramki Krishnan; [email-masked]
Subject: Re: [OPSAWG] Fwd: New Version Notification for draft-fan-opsawg-packet-loss-01.txt

Hi Ramki,

Regards,
Peng

> >> If this method is to be used on a router, one is advised to make 
> >> sure that the ICMP packets experience the same  forwarding and 
> >> discarding
> courses as the service traffic (of  which the packet loss rate is to 
> I wouldn’t quite agree with this. The reason it is done so today is to 
> prevent ping flood type of DDoS attacks
> 
> Thanks,
> Ramki
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ramki Krishnan
>  advised to make sure that the ICMP packets experience the same  
> forwarding and discarding courses as the service traffic (of  which 
> the packet loss rate is to be measured) does, otherwise the measurement will not make sense.
> 
> I wouldn’t quite agree with this. The reason it is done so today is to 
> prevent ping flood type of DDoS attacks.
> 
> Thanks,
> Ramki
> 
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Fan Peng
> The document aims to review methods for packet loss rate measurement 
> and problems with them, and provide some guidelines when performing 
> the measurement. The document is based on operational experience and 
> needs especially when doing performance monitoring on the 
> interconnecting link between two providers' networks. We also hope we 
> can find after the discussion a measurement scheme that is convenient 
> enough and provides consistent results.
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 6 Aug 2013 07:33:36 -0700

On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng <[email-masked]> wrote:

>
> A basic requirement for using ICMP (and other active measurement
> approaches) is to let probing traffic and service traffic have the same
> drop probability, though it is usually difficult to guarantee this.
>

It seems like this would be further complicated if something like ECN is in
use.  While ECT packets would be marked with CE and thus not contribute to
the loss rate, ICMP packets would end up being discarded.

Anoop

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 6 Aug 2013 18:35:03 +0000

There are two other considerations:

1. ICMP packets might follow a different path than the application in the presence of ECMP
2. The ICMP responder might rate limit and drop if it's a router regardless of the drop characteristics of the path -- RFC 6192.

Thanks,

Thumb typed by Carlos Pignataro.
Excuze typofraphicak errows

On Aug 6, 2013, at 4:33 PM, "Anoop Ghanwani" <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Aug 5, 2013 at 8:54 PM, Fan, Peng <[email-masked]<mailto:[email-masked]>> wrote:

A basic requirement for using ICMP (and other active measurement approaches) is to let probing traffic and service traffic have the same drop probability, though it is usually difficult to guarantee this.

It seems like this would be further complicated if something like ECN is in use.  While ECT packets would be marked with CE and thus not contribute to the loss rate, ICMP packets would end up being discarded.

Anoop
_______________________________________________
OPSAWG mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Fan, Peng" <[email-masked]>
Date: Wed, 7 Aug 2013 16:17:50 +0800

Dear Carlos, Anoop,

We shall take these items into consideration. The first thing we have to do
is to reconsider the scope and architecture of the draft. Thank you for
reminding!

Regards,

Peng

From: Carlos Pignataro (cpignata) [mailto:[email-masked]] 
Sent: Wednesday, August 07, 2013 2:35 AM
To: Anoop Ghanwani
Cc: Fan, Peng; [email-masked]
Subject: Re: [OPSAWG] Fwd: New Version Notification for
draft-fan-opsawg-packet-loss-01.txt

1. ICMP packets might follow a different path than the application in the
presence of ECMP

2. The ICMP responder might rate limit and drop if it's a router regardless
of the drop characteristics of the path -- RFC 6192. 

Thanks,

On Aug 6, 2013, at 4:33 PM, "Anoop Ghanwani" <[email-masked]> wrote:

A basic requirement for using ICMP (and other active measurement approaches)
is to let probing traffic and service traffic have the same drop
probability, though it is usually difficult to guarantee this.

Anoop