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

Fernando Gont <fernando@gont.com.ar> Wed, 01 December 2010 21:54 UTC

Return-Path: <fernando.gont.netbook.win@gmail.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 51F9B3A672F for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 13:54:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 y+t8DMJ2jcvQ for <tsvwg@core3.amsl.com>; Wed, 1 Dec 2010 13:54:56 -0800 (PST)
Received: from mail-gy0-f194.google.com (mail-gy0-f194.google.com [209.85.160.194]) by core3.amsl.com (Postfix) with ESMTP id 5E94B3A63EB for <tsvwg@ietf.org>; Wed, 1 Dec 2010 13:54:56 -0800 (PST)
Received: by gyd8 with SMTP id 8so4708313gyd.1 for <tsvwg@ietf.org>; Wed, 01 Dec 2010 13:56:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:x-enigmail-version:openpgp :content-type:content-transfer-encoding; bh=Dwh95pQPP9IsQijtvBkqr8vXzFY5KkCQedJXpOvu5Pc=; b=i1buBvoJRCnUtlxaXcDxifTPkGp2av9OQyP3Z7KHZAvZbNFagohatSSNH6gvX8t5KW WboLpnOLFP9MZxDeTYRxf669vbAC2vwKPFJ7TzGxpKW3QrubaiVsTNeOMEDOYaA0ULH/ +QCidW1hnKHSXGuvZnVjUHKVblIebHps/X9Hs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; b=QRXNhqpL6RePgG76Bqby6BnSFgGHhtjaBfSg0YcqfFnJBNZPt1SMO2Yjv/mY6+Ph6G JaBUtASpg7OXnJ7If9TMUuwCD7PAljV40cmJNFVTAelyKlBLgXhxdrVEi2zqGiTHD6NB EnXAx9SJ8KCATnwYZkvkzXekNtNfzsaVTcUJA=
Received: by 10.91.66.18 with SMTP id t18mr2271152agk.191.1291240570413; Wed, 01 Dec 2010 13:56:10 -0800 (PST)
Received: from [192.168.2.3] (92-129-17-190.fibertel.com.ar [190.17.129.92]) by mx.google.com with ESMTPS id c7sm427079ana.17.2010.12.01.13.56.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 01 Dec 2010 13:56:09 -0800 (PST)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4CF6C471.9070304@gont.com.ar>
Date: Wed, 01 Dec 2010 18:56:01 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2
MIME-Version: 1.0
To: tsvwg <tsvwg@ietf.org>
Subject: Summary of proposed changes to draft-gont-tsvwg-source-quench
X-Enigmail-Version: 1.1.1
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "gorry@erg.abdn.ac.uk" <gorry@erg.abdn.ac.uk>, Fred Baker <fred@cisco.com>, 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 21:54:57 -0000

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.

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


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)


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.


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)


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.


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