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

[Gorry Fairhurst <[e-mail]>]

On 20/10/2011 18:25, Joe Touch wrote:
> 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
>
> On 10/20/2011 8:09 AM, Fernando Gont wrote:
>> 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,
>
>
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