Subject: Re: WGLC Announcement for draft-ietf-tsvwg-source-quench - 18th October 2011,

From: [email-masked] (Scott O. Bradner)
Date: Tue, 18 Oct 2011 08:05:05 -0400 (EDT)

why does section 6 use SHOULD rather than MUST?

seems to me that there are no known cases where any transport protocol
should ever respond to a Source Quench

Scott

---

From: Joe Touch <[email-masked]>
Date: Tue, 18 Oct 2011 14:20:52 -0700

I had suggested:

MUST ignore

SHOULD NOT send

The latter is weaker because there is no impact if a message is sent. However, I do prefer use of SHOULD only with at least one known exception provided, or at least a clear metric to know when the exception is appropriate. 

In this case SHOULD should not be driven by legacy cases. 

Joe

---

From: Fernando Gont <[email-masked]>
Date: Thu, 20 Oct 2011 12:09:11 -0300

Hi, Joe,

Thanks for your input! Please find my comments inline...

On 10/18/2011 06:20 PM, Joe Touch wrote:
> I had suggested:
> 
> MUST ignore
> 
> SHOULD NOT send
> 
> The latter is weaker because there is no impact if a message is sent.

Is there any valid reason *for* sending SQs?

My understanding of Scott's point is that the motivation for a "SHOULD
NOT" rather than "MUST NOT" should be that there are exceptions under
which it could make sense to behave in a different way (rather than
whether there may be a negative impact if the advise is not followed).

So I'd agree with Scott that this should be "MUST NOT send, MUST ignore
if received".

Thoughts?

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 10:25:21 -0700

Hi, Fernando,

My view:

- the doc needs MUST ignore on receipt

Anything beyond that isn't needed. If it's ignored, there's no point in 
sending it, but it does no harm.

I would prefer to not even make a statement about whether to send it.

A MUST NOT send could be (mis)interpreted as an opportunity for (yet 
another) needless suggestion that it should be interpreted as either an 
attack or a formal error worth reporting.

Joe

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 20 Oct 2011 20:51:49 +0100

>> So I'd agree with Scott that this should be "MUST NOT send, MUST ignore
I wondered on this bit:

"   If a Source Quench message is received by any other transport-
    protocol instance (e.g., a UDP-based protocol), it SHOULD be silently
    ignored."

While I agree it's fair to say such behavior is inappropriate for TCP 
and SCTP, I'm finding it harder to say that a UDP app MUST never respond 
to a SQ.

In the end, I think that from my point of view (no chair hat, etc) there 
were no good reasons why an arbitrary UDP application program could 
decide not decide to react to SQ messages.

Such an application would need to not care about optimising transmission 
rate (since a SQ does not really help in choosing a suitable rate, it 
just provides an indication that it may be good to reduce at this time). 
However, this could be good enough in a few cases, i.e. an application 
that really fears it may be hurting others *could* decide abort to 
abort. That would not really hurt the Internet.

It would be good for the application's own safety of course that it 
checks the conditions under which these messages were received. It would 
also be reasonable to expect not to receive these from a modern Internet 
router, if this document does obsolete this.

On the other hand, there may be better ways to detect congestion:-).

Is this inconsistent or not? Someone help me think.

I note Joe's comment on being silent on router sends, or laternatively 
saying that routers "SHOULD NOT" send.

Gorry

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 20 Oct 2011 22:11:22 +0200

* Gorry Fairhurst | 2011-10-20 20:51:49 [+0100]:

>and SCTP, I'm finding it harder to say that a UDP app MUST never
>respond to a SQ.
>
>In the end, I think that from my point of view (no chair hat, etc)
>there were no good reasons why an arbitrary UDP application program
>could decide not decide to react to SQ messages.

Mhh, right. But on the other hand: there is no (suitable) protection for UDP
to detect forged SQ messages (e.g. no sequence field).  Every instance can
forge malicious SQ messages and send to any UDP instance.  From a security
point of view UDP/UDPLite SHOULD ignore SQ messages too.

After consensus on that (I hope that the security aspect is a legitimate
aspect too) I am not aware of any transport protocol where SQ makes sense.

Hagen

---

From: Joe Touch <[email-masked]>
Date: Thu, 20 Oct 2011 14:09:37 -0700

On 10/20/2011 1:11 PM, Hagen Paul Pfeifer wrote:
> to detect forged SQ messages (e.g. no sequence field).

That won't help anyway. As with any router messages, there's no rule for 
how timely the message is, so the sequence number could easily be out of 
range (or even roll-over) by the time the message is sent.

Sequence numbers in ICMP messages communicate NOTHING.

> Every instance can

AFAICT, this is the only sensible response.

I.e., although SQ-like messages might be more useful to UDP than to 
other protocols, SQ itself as currently defined is not.

> aspect too) I am not aware of any transport protocol where SQ makes sense.

With the caveat that "SQ as currently spec'd", +1

Joe

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 20 Oct 2011 23:30:41 +0200

* Joe Touch | 2011-10-20 14:09:37 [-0700]:

>That won't help anyway. As with any router messages, there's no rule
>for how timely the message is, so the sequence number could easily be
>out of range (or even roll-over) by the time the message is sent.

Right Joe, maybe too late ... :)

>With the caveat that "SQ as currently spec'd", +1

+1 (for the ID)

Hagen