Re: [tcpm] ECN++

[Bob Briscoe <[e-mail]>]

Richard,

On 15/01/2020 20:42, Scheffenegger, Richard wrote:
>
> Hi,
>
> Yet another interesting observation – as fbsd currently doesn’t refrain
> from marking SACK-retransmission to be not-ECT, you can actually end up
> getting a CE mark on a retransmission across a ECN-enabled congestion 
> point.
>
> Obviously this is better than loss…
>
> What happens next is, that fbsd "honors" that ECE mark, since it is in
> loss-recovery, not congestion-recovery. It adjusts the recovery_point to
> the current snd_max (rightmost sent segment), and adjusts ssthresh and
> cwnd by multiplicative decrease factor...
>
> Furthermore, it appears that it also resets the traversal of the SACK
> scoreboard (incidential a "good" thing, as a few earlier retransmissions
> also got dropped, not marked, and are being resent without an RTO).
>
> But in the context of ECN++, what would be the expected response here?
[BB] Quoting 3.2.7.  Retransmissions (Send)
https://tools.ietf.org/html/draft-ietf-tcpm-generalized-ecn-05#section-3.2.7

    If the TCP sender receives feedback that a retransmitted packet was
    CE-marked, it will react as it would to any feedback of CE-marking on
    a data packet.

In the ECN++ draft, we tried not to be too prescriptive or inventive 
about congestion behaviour. The draft is intended to focus on the 
sender's wire protocol behaviour, and refer to the default congestion 
response but not require it, so that other congestion control schemes 
can specify different responses without having to update the ECN++ draft.


Bob
>
> I assume, that with the exception of the fresh traversal of the SACK
> scoreboard, the above steps seem sensible.
>
> Any thoughts on this interesting interaction between ECE (during SACK
> loss recovery)?
>
> Best regards,
>    Richard
>
>
>
> Am 10.01.2020 um 01:08 schrieb Scheffenegger, Richard:
>> Marcelo, Bob,
>>
>> I just noted that there is a slight oversight in FreeBSD currently,
>> which results in all session that are simultaneously ECN-enabled and
>> SACK-permitted to effectively send out retransmissions with the ECT0
>> codepoint.
>>
>> Strictly speaking, this is in violation of RFC3168, but might also be a
>> good (nearly a decade long) validation of the performance of ECN++ for
>> all types of data segments (new and retransmitted ones), although at a
>> low and implicit exposure...
>>
>>
>> On that note, since I think ECN++ is quite valuable (with a number of
>> published research finding this change to be crucial), perhaps you can
>> summarize the outstanding issues (other than more reviewers required; I
>> admit I still haven't gone through all the delta between -04 and -05).
>>
>> Best regards,
>>    Richard
>>
>> _______________________________________________
>> tcpm mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tcpm
>

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