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

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Dec 2010 18:56:01 -0300

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: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Dec 2010 16:54:59 -0600

> SQ does not raise interoperability problems.

I believe it is.

> 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.

> requirements for routers with the requirements for hosts (of ignoring

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.

> the IP layer MAY silently discard it.

Whatever. See previous comment.

> normative language here, though)

Whatever. See previous comment.

> More comments needed/wanted.

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Dec 2010 20:20:51 -0300

Hi, Fred,

>> 2) Update the text in RFC 1812 that states "A router MAY ignore any
>> ICMP Source Quench messages it receives".
>> 
>> 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? 

Not that I know of. There were, but they were updated while we were
producing RFC 5927 (see e.g.:
http://www.cisco.com/en/US/products/products_security_advisory09186a0080436587.shtml)

> Do you expect folks to be building new IPv4 routers at some
> point in the future? 

Yes, as much as they build new IPv6 routers. -- put another way, I don't
think ipv6-only routers will be shipped in the near term. e.g., anyone
entering the business would have to implement both IPv4 and IPv6 (unless
they base their products on existing code, of course).

>> 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. 

Historic?

> Are there any SQuID implementations? 

Not that I know of. -- Could double-check, though.

> What would happen if we declared SQuID obsolete?

I guess it would be easier for a newcomer looking at the specs to figure
out that he should not bother with SQuID. (i.e., this is just
cleaning-up the specs tree).

Thanks!

Kind regards,

---

From: Fred Baker <[email-masked]>
Date: Wed, 1 Dec 2010 21:15:52 -0600

> they base their products on existing code, of course).

Two different questions. If I build a new bit of hardware and port an old bit of code to it, it will still do what the old bit of code did. Yes, there will be routers that implement IPv4 functionality; there are currently "new" routers that implement DECNET IV, XNS, Novell Netware, and OSI CLNS. Are there any that will do so with new functionality? Not on your life.

Are you expecting folks to build IPv4 routers that try to interpret source quench?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Dec 2010 01:05:27 -0300

On 02/12/2010 12:15 a.m., Fred Baker wrote:

>>> Do you expect folks to be building new IPv4 routers at some point
>>> in the future?
>> 
>> Yes, as much as they build new IPv6 routers. -- put another way, I
>> don't think ipv6-only routers will be shipped in the near term.
>> e.g., anyone entering the business would have to implement both
>> IPv4 and IPv6 (unless they base their products on existing code, of
>> course).
> 
> Two different questions. If I build a new bit of hardware and port an
> old bit of code to it, it will still do what the old bit of code did.
> Yes, there will be routers that implement IPv4 functionality; there
> are currently "new" routers that implement DECNET IV, XNS, Novell
> Netware, and OSI CLNS. Are there any that will do so with new
> functionality? Not on your life.

Agreed. However, there's no existing requirement that everybody should
base his products on someone else's code.

In theory, a product implementing IPv4 from scratch would base its
implementation on the RFCs.

-- Yeah, I know... in practice most products are based on someone else's
code (whether legally or not), and the RFCs tend to be outdated, so it's
not really possible to comply with them.

> Are you expecting folks to build IPv4 routers that try to interpret

I'm expecting folks to build IPv4 routers, and I'm expecting people to
implement stuff that the RFCs tell them that they MUST/SHOULD/MAY
implement (and sometimes not even that) -- from my perspective, the less
an implementer has to figure out by himself, the better.

IMO, at least for every protocol that is still expected to be
implemented, the IETF should do the maintenance of the corresponding
specifications -- and that includes formally obsoleting features that
have become obsolete.

FWIW, I know of vendors that run "RFC-compliance" tests, for which it
does matter that they implement what the RFCs mandate -- whether this is
clever or not, is a different story. But performing the proper
specifications maintenance help these folks, too.

Thanks,

---

From: "DeSimone, Antonio" <[email-masked]>
Date: Thu, 2 Dec 2010 17:16:35 -0500

On 12/1/10 4:56 PM, "Fernando Gont" <[email-masked]> wrote:

Fernando,

Looks good.

> "MUST NOT generate ICMP SQ".

agree--consenting implementations and all that...

> requirements for routers with the requirements for hosts (of ignoring

agree

> the IP layer MAY silently discard it.

agree

> normative language here, though)

agree

> Source Quench Introduced Delay (SQuID)")

It's not a big deal either way, but I'd just leave RFC1016 out of it.  It's
just, as it says, a crazy idea.

I think I made the comment before that some of this is academic.  In that
sense I agree with Fred's opinion that much of this is not likely to affect
real implementations.  However, if we're going to produce an update I think
we should be a complete as practical, especially if there are MUST
statements in standards related to SQ--that's why I brought up 1122.  For
better or for worse, there are people who take a "checklist" approach to RFC
compliance.  Actually, almost never for better :).