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

[Bob Briscoe <[e-mail]>]

Rod,

On 12/07/2019 15:39, Rodney W. Grimes wrote:
>> Rod,
>>
>> This draft appears to be focused on obtaining a TCP header bit for SCE.
> Yes, that is correct.
>
>> As an alternative to this single-bit proposal, please take a look at draft-ietf-tcpm-accurate-ecn (https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/) and consider how that functionality might (or might not) be usable with SCE.
> I specifically did not do what Accurate Ecn attempts as that requires
> a TCP option negotiation at connection establishment to negotiate the
> overloading of other TCP header bits.  SCE only needs 1 new bit, and
> does not alter the behavior of any current bits.
Just to correct this slightly - in AccECN, there is no explicit TCP 
option negotiation. Negotiating use of the 3 header bits also implicitly 
states that the endpoints might have implemented the TCP option. 
However, it's not mandatory to send the option (it is recommended), and 
it's not mandatory to even implement the logic to read in the option 
(that is highly recommended). Reason: the protocol has to be able to 
work even if the option is stripped on the path.

>
> This proposal (TCPSCE) does not in any way effect the current use of
> any of the other bits, and use of the NS bit should be fully backwards
> compatible and ignored by pre SCE implementations and does not require
> a TCP option negotiation.
>
> I have to get additional data but have been lead to understand that
> adding a tcp option and doing that negotiation is going to cause a
> great deal of pain in the ability to deploy accurate ecn as it is
> currently designed due to middle box inspection and handling.
There's already been concern about burning TCP header codepoints, which 
might use up space that prevents something in future. The idea of AccECN 
is to enable generic more accurate feedback. It was based on a 
protracted requirements-gathering exercise [RFC7560], and lots of 
compromising along the way.

The idea was to have a generic wire protocol with a dumb receiver, so 
that the same feedback protocol could support multiple needs for 
feedback by different TCP congestion control algorithms.

So a fairly inefficient re-use of the 'NS' TCP header flag for one 
particular experiment is very unlikely to fly, particularly when the 
experiment it supports doesn't satisfy all the requirements in 7560.

For instance, I think the reason the tcpsce draft discusses multiple 
ways of doing the feedback is that, in the presence of pure ACK loss 
(which is often due to deliberate ACK thinning), none of the three 
solutions preserve reliable delivery of the ACK signal.

In the case of Single ACK (4.1), the additional ACK load would be 
unacceptable.

In the case of immediate ACKing of an IP-SCE (not delaying the ACK - 
S.4.2), it introduces bias (i.e. a higher proportion of ESCE ACKs to 
non-ESCE), so it becomes hard/impossible for the sender to reverse 
engineer what congestion feedback level was intended.

In the case of dithering (4.3), the congestion signal frequently becomes 
deferred (and there may not be a next packet for some time).

The requirements [RFC7560] recognise that this is a multi-dimensional 
compromise so any solution had to explain the rationale for its 
particular choices.

However, I don't think this solution is anywhere near as efficient in 
its use of the limited bit-space as many of the other rejected AccECN 
proposals have been, let alone the currently chosen one.


Bob

>
> Regards,
> Rod
>
>> Thanks, --David
>>
>>> -----Original Message-----
>>> From: tsvwg <[e-mail]> On Behalf Of Rodney W. Grimes
>>> Sent: Monday, July 8, 2019 8:07 PM
>>> To: [e-mail]; [e-mail]
>>> Subject: [tsvwg] New Version Notification for draft-grimes-tcpm-tcpsce-
>>> 00.txt
>>>
>>>
>>> [EXTERNAL EMAIL]
>>>
>>> I have posted a new version with updated proper tcpm working group
>>> name of draft-grimes-tcpm-tcpsce-00
>>> (formerly draft-grimes-tcpmwg-tcpsce-00.txt)
>>>
>>> This is first cut at how SCE works in TCP
>>>
>>> Cross posting this to both tsvwg and tcpm due to overlap
>>>
>>>
>>>> A new version of I-D, draft-grimes-tcpm-tcpsce-00.txt
>>>> has been successfully submitted by Rodney W. Grimes and posted to the
>>>> IETF repository.
>>>>
>>>> Name:		draft-grimes-tcpm-tcpsce
>>>> Revision:	00
>>>> Title:		Some Congestion Experienced in TCP
>>>> Document date:	2019-07-08
>>>> Group:		Individual Submission
>>>> Pages:		5
>>>> URL:            https://www.ietf.org/internet-drafts/draft-grimes-tcpm-tcpsce-
>>> 00.txt
>>>> Status:         https://datatracker.ietf.org/doc/draft-grimes-tcpm-tcpsce/
>>>> Htmlized:       https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-00
>>>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-grimes-tcpm-
>>> tcpsce
>>>>
>>>> Abstract:
>>>>     This memo classifies a TCP code point ESCE ("Echo Some Congestion
>>>>     Experienced") for use in feedback of IP code point SCE ("Some
>>>>     Congestion Experienced").
>>> --
>>> Rod Grimes                                                 [e-mail]
>>
>>

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