Subject: Re: [tcpm] Detailed review of AccECN rev -04

From: Bob Briscoe <[email-masked]>
Date: Sat, 14 Jul 2018 17:00:13 +0100

Gorry, Mirja,

While reviewing conversations on the list for including in our slides in 
Montreal, I thought again about the conversation below from March...

On 13/03/18 16:49, Gorry Fairhurst wrote:
>>> A future standards-track document based on the AccECN experimental 
>>> RFC could update RFC3168.
>>
>> No, I don’t it would update RFC3168. It does not change anything in 
>> that RFC. It also specified an additional meachismen (which we hope 
>> will deploy as the default). The only thing we change is the use of 
>> the NS bit in the SYN but that was previously unused; with or without 
>> ECN Nonce.
>>
> OK that makes sense. 

Although nothing in AccECN updates RFC3168, the goal was not to fork the 
wire protocol, but instead to eventually provide a generic wire protocol 
that could either feed back to a host behaving like RFC3168 (one 
response per RTT) or behaving with an updated behaviour (e.g. L4S).

So, some time in the future we might want to work out whether / how to 
update RFC3168 with a new standards track feedback protocol.

Bob

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

---

From: G Fairhurst <[email-masked]>
Date: Sun, 15 Jul 2018 10:31:52 -0400

OK, it makes sense and I agree. I think that's a key difference with the 
ABE ID. That does change RFC3168, by specifying a different  mechanism 
to respond to feedback, which we expect will deploy as the default for 
ECT(0).

Gorry

On 14/07/2018, 12:00, Bob Briscoe wrote:
> Gorry, Mirja,
>
>
> While reviewing conversations on the list for including in our slides 
> in Montreal, I thought again about the conversation below from March...
>
>>> the NS bit in the SYN but that was previously unused; with or 
>>> without ECN Nonce.
>>>
>> OK that makes sense. 
>
> Although nothing in AccECN updates RFC3168, the goal was not to fork 
> the wire protocol, but instead to eventually provide a generic wire 
> protocol that could either feed back to a host behaving like RFC3168 
> (one response per RTT) or behaving with an updated behaviour (e.g. L4S).
>
> Bob Briscoehttp://bobbriscoe.net/