RE: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01)

[<[e-mail]>]

> > If others weigh in, and agree on that, I could s/deprecates reaction to
> > ICMP Source Quench messages by transport protocols such as
> > TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/.
> >
> Let's discuss that one on the list!

> >> /the IP layer MAY silently discard it./
> >> - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore
> >> a source quench that it receives."
> >
> > The point is that this is a specific update to RFC 1122, which talks
> > about hosts, not routers.
> >
> > Thoughts?
> >
> We could update router behaviour too, if TSVWG wants. It's a transport
> signal.

I strongly suggest doing this once and deprecating Source Quench everywhere.
If that means updating additional RFCs, I have no problem with doing so.

Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Gorry Fairhurst
> Sent: Wednesday, January 26, 2011 3:58 PM
> To: Fernando Gont
> Cc: tsvwg list
> Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01)
> 
> See in-line...
> 
> On 26/01/2011 20:11, Fernando Gont wrote:
> > Hi, Gorry,
> >
> > Thanks so much for your feedback. Should I resubmit as draft-ietf once I
> > address these?
> >
> > Please find my comments inline...
> >
> > On 26/01/2011 04:38 p.m., Gorry Fairhurst wrote:
> >> Abstract:
> >>
> >> I recommend you add more detail here, saying what documents are updated.
> >
> > Ok, will do.
> >
> >
> >
> >> Introduction:
> >>
> >> /The ICMP specification [RFC0792] defines the ICMPv4 Source Quench
> >>     message (type 4, code 0), which is /
> >>                                     ^^
> >> - change to "was", since we now declare this as historic?
> >
> > Should I put the whole sentence in past tense? i.e. "defined... which was"?
> >
> I'd suggest so.
> >
> >>
> >> /for a long time/
> >> - perhaps we should just say the year - i.e. 1995.
> >
> > Will do.
> >
> >
> >
> >> /   This document formally deprecates reaction to ICMP Source Quench
> >>     messages by transport protocols such as TCP./
> >> - Should we consider deprecating it for all IPv4 nodes? I think it
> >> effectively does this, including endpoints that do not constitute
> >> transports.
> >
> > Well, the point is that other than the minor updates to RFC1812, this
> > document formally deprecates the reaction to SQ by TCP -- right now,
> > e.g. TCP is still required to slow down upon receipt of ICMP SQ.
> >
> > If others weigh in, and agree on that, I could s/deprecates reaction to
> > ICMP Source Quench messages by transport protocols such as
> > TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/.
> >
> Let's discuss that one on the list!
> >
> >
> >> Section 3:
> >>
> >> /We hereby/
> >> - Could we say "This document hereby"...
> >
> > Will do.
> >
> >
> >
> >> /message (type 4, code 0), which is /
> >> - see note on intro.
> >
> > Ditto -- past tense for the whole thing?
> >
> >
> >
> >> /[RFC1812] notes that research suggests/.../and formally deprecates/
> >> - 'noted', 'suggested', and 'deprecated'?
> >
> > Depending on what's your take for the other instances... but yes, I
> > think that would sound good to me.
> >
> >
> >
> >> /the IP layer MAY silently discard it./
> >> - I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore
> >> a source quench that it receives."
> >
> > The point is that this is a specific update to RFC 1122, which talks
> > about hosts, not routers.
> >
> > Thoughts?
> >
> We could update router behaviour too, if TSVWG wants. It's a transport
> signal.
> >
> >
> >> Section 6.:
> >>
> >> - My first thoughts are also that it is good to make this
> >> "memo" historic (RFC1016). See what others think.
> >
> > So no changes here, right?
> >
> That's my "non-chair" position too :-)
> 
> > -- FWIW, what's in the current version of the I-D is what I've sensed as
> > consensus as a result of the discussions on ICMP SQ on this mailing-list.
> >
> OK
> >
> >> References:
> >>
> >> - I'm not sure that [RFC4443] is normative. Please check.
> >
> > Yes, I think that in this case it could be informative. Will do.
> >
> >
> >
> >> - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a
> >> normative reference?
> >
> I meant ECN, not 3136.
> 
> > I think "these are important to understand this document", which would
> > make them "normative"...
> >
> Although you need to understand them, the changes you are making do not
> modify these documents, so I'd still say they are not normative - but we
> can handle later in LC.
> 
> > Thanks!
> >
> > Best regards,
>  >
> I'd suggest you do all the changes you feel confident with, and we can
> discuss any remaining issues on the list. Can you summarise any
> remaining points you recall?
> 
> 
> Finally, with my "Chair" hat on:
> 
> You may upload the next version as a WG I-D.
> 
> Gorry
>