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

[Fernando Gont <[e-mail]>]

Folks,

FYI, feedback by Andrew Yourtchenko.

FWIW, Dan Wing and Scott Bradner agreed with my notes, too (off-list).

Thanks!

Kind regards,
Fernando




-------- Original Message --------
Subject: Re: Fwd: Summary of proposed changes to
draft-gont-tsvwg-source-quench
Date: Wed, 1 Dec 2010 23:14:04 +0100 (CET)
From: Andrew Yourtchenko <[e-mail]>
To: Fernando Gont <[e-mail]>

Hi Fernando,

On Wed, 1 Dec 2010, Fernando Gont wrote:

> Hi, Andrew,
>
> BTW, interested in your comments -- if you have any.

thanks for the opportunity! Inline below, nothing major...

cheers,
andrew

>
> Thanks!
>
> Kind regards,
> Fernando
>
>
>
>
> -------- Original Message --------
> Subject: Summary of proposed changes to draft-gont-tsvwg-source-quench
> Date: Wed, 01 Dec 2010 18:56:01 -0300
> From: Fernando Gont <[e-mail]>
> To: tsvwg <[e-mail]>
> CC: Fred Baker <[e-mail]>,  "[e-mail]"
> <[e-mail]>, Dan Wing <[e-mail]>,
> [e-mail],  "Mahesh Jethanandani (mahesh)"
> <[e-mail]>
>
> 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.
>

agree with this.

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

I suppose they are rate-limited, so this is a bit far-fetched scenario
imho :-)

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

I think from the practical standpoint it would not matter much, so I am
in "weak
agreement" on this one.

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

+1.

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

+1.

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

quote from RFC1016: "This is an "crazy idea paper" and discussion is
essential."

As such I don't think it is worth obsoleting - as far as I see it does
not have
any status at all.

>
> 6) Note that ICMPv6 didn't bother to specify an IPv6 version of ICMP SQ
> (this is just an informational note)

makes sense.

cheers,
andrew

>
> Thanks!
>
> Kind regards,
> -- 
> Fernando Gont
> e-mail: [e-mail] || [e-mail]
> PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1
>
>
>
>