Re: Summary of proposed changes to draft-gont-tsvwg-source-quench

Fred Baker <fred@cisco.com> Wed, 01 December 2010 22:54 UTC

Return-Path: <fred@cisco.com>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A38243A6809 for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 14:54:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.435
X-Spam-Level:
X-Spam-Status: No, score=-110.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZwG0ryO8yR1t for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 14:54:02 -0800 (PST)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3D8753A6802 for <tsvwg@ietf.org>; Wed, 1 Dec 2010 14:54:01 -0800 (PST)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.59,285,1288569600"; d="scan'208";a="386647582"
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 01 Dec 2010 22:55:14 +0000
Received: from Freds-Computer.local (sjc-vpn3-624.cisco.com [10.21.66.112]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oB1Mt9re000627; Wed, 1 Dec 2010 22:55:14 GMT
Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Wed, 01 Dec 2010 16:55:14 -0500
X-PGP-Universal: processed; by Freds-Computer.local on Wed, 01 Dec 2010 16:55:14 -0500
Subject: Re: Summary of proposed changes to draft-gont-tsvwg-source-quench
Mime-Version: 1.0 (Apple Message framework v1082)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <4CF6C471.9070304@gont.com.ar>
Date: Wed, 1 Dec 2010 16:54:59 -0600
Message-Id: <EB90E34A-D9F1-4EA6-B350-23BB9E331EC0@cisco.com>
References: <4CF6C471.9070304@gont.com.ar>
To: Fernando Gont <fernando@gont.com.ar>
X-Mailer: Apple Mail (2.1082)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>, Dan Wing <dwing@cisco.com>, Antonio.DeSimone@jhuapl.edu
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Dec 2010 22:54:03 -0000

On Dec 1, 2010, at 3:56 PM, Fernando Gont wrote:

> Folks,
> 
> I plan to produce a revision of the aforementioned I-D soon. These are
> the changes that have so far been proposed to the current I-D, and my
> read of where consensus seems to be.
> 
> Please respond to each of these:
> 
> 1) Do *not* update the "SHOULD NOT generate ICMP SQ" in RFC 1812 to
> "MUST NOT generate ICMP SQ".
> 
> My read of the comments received so far is that the current "SHOULD NOT
> generate ICMP SQ" text in RFC 1812 is fine "as is", as generating ICMP
> SQ does not raise interoperability problems.

I believe it is.

> (although I guess some might argue that since ICMP SQ consumes
> bandwidth, this might exacerbate congestion?)

It might very well. This is one of the biggest issues with ICMP SQ; the next issue is "what to do with it if you receive it". In TCP or SCTP, doing something comparable to what ECN CE does probably makes sense. Undefined for UDP and DCCP based applications.

> 2) Update the text in RFC 1812 that states "A router MAY ignore any ICMP
> Source Quench messages it receives".
> 
> The resulting text would s/MAY/SHOULD/. This would align the
> requirements for routers with the requirements for hosts (of ignoring
> ICMP SQs)

Perhaps. Personally, I think this is a matter of polishing the barn door. Are there any routers now that try to interpret a Source Quench? Do you expect folks to be building new IPv4 routers at some point in the future? As you note, ICMPv6 doesn't include Source Quench, so for anything developed with the future in mind doesn't have this problem.

> 3) Update the text in RFC 1122 that states "If a Source Quench message
> is received, the IP layer MUST report it to the transport layer (or ICMP
> processing)."
> 
> The resulting text would read: "If a Source Quench message is received,
> the IP layer MAY silently discard it.

Whatever. See previous comment.

> 4) Update the security considerations section noting that most host
> implementation currently ignore ICMP SQ (as noted in RFC 5927), and
> mention that they could be filtered at firewalls if deemed necessary (no
> normative language here, though)

Whatever. See previous comment.

> 5) Have this document obsolete RFC 1016 (Prue, W., and J. Postel, "The
> Source Quench Introduced Delay (SQuID)")
> 
> So far I have received one positive comment about this one (off-list).
> More comments needed/wanted.

Or make it experimental. Are there any SQuID implementations? What would happen if we declared SQuID obsolete?

> 6) Note that ICMPv6 didn't bother to specify an IPv6 version of ICMP SQ
> (this is just an informational note)
> 
> Thanks!
> 
> Kind regards,
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
> 
> 
> 
>