Re: [tcpm] [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-00.txt

[Bob Briscoe <[e-mail]>]

Jonathan,

On 22/07/2019 10:48, Jonathan Morton wrote:
>> On 21 Jul, 2019, at 9:01 pm, Scharf, Michael <[e-mail]> wrote:
>>
>> Please be aware that there is also draft-ietf-tcpm-generalized-ecn-04, which in the current version has a dependency on draft-ietf-tcpm-accurate-ecn for certain cases.
>>   
>> Just to state the obvious: These documents are work in progress in TCPM and TCPM always welcomes feedback.
> I just skimmed through it to remind myself of certain details.  Most of it only applies once AccECN has completed negotiation, so the same arguments apply.
Actually in 2 out of 7 cases, not "most". See table 1 in the spec, which 
is intended for people who skim.
>
> I do however note that SYN is described as the most important packet to protect with ECN, and this is of course sent before AccECN negotiation has completed.  Further, if the SYN-ACK then indicates that AccECN is *not* supported by the remote end - which would be the case for both an SCE endpoint and any conventional one - a conservative IW of 1 segment SHOULD be conservatively selected, with no modification for the increasingly common IW10 case (the default for current versions of Linux).  This incurs a flow completion time delay of approximately 3 RTTs, which could be perceptible to end users.
The draft explains: the reduction to IW1 is in the client to server 
direction. It cites measurement studies that show it's unusual to get >1 
initial packet in that direction anyway. And the reduction to 1 is only 
a SHOULD. An implementation could choose 2 for instance.

When new to the IETF, it's even more important to read the draft before 
sending critique (cos you won't have heard all the previous discussion). 
Otherwise it burns busy people's time on the list unnecessarily.

>
> A less extreme response may be justified here, given that the strongest signal that may have been missed by the lack of ECN feedback is a CE mark, for which the most conservative TCP response is to halve the cwnd.  So for an IW4 sender, the IW should be reduced to 2, and for an IW10 sender, the IW should be reduced to 5.  This would reduce the flow completion penalty to 1 RTT when encountering a non-AccECN endpoint.
Again, pls read the rationale for fall-back to IW1 in the draft. 
(There's a whole rationale section after the normative text section, 
with linked referenced from each section of it).

Briefly, if you get a CE, it implies the queue was up to it's marking 
threshold 1 RTT ago, presumably with traffic from another flow(s). So 
adding more than 1 packet is likely to be pointless and 
counterproductive for them and you.

But this is only a SHOULD, cos experiments might prove IW1 is 
unnecessary (if anyone is motivated to bother because they have an app 
that starts with >1 request data packet).



Bob

>
>   - Jonathan Morton
>
>

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/