Re: [tcpPrague] New Version Notification for draft-ietf-tcpm-accurate-ecn-02.txt

[Bob Briscoe <[e-mail]>]

Mirja,

During the discussion on draft-briscoe-tsvwg-ecn-l4s-id, you raised the 
concern about the CE marking being ambiguous (it could have been ECT(0) 
or ECT(1) before marking). The draft says why there is a low risk CE 
marks will arrive at a second bottleneck, and why the risk of causing 
spurious retransmissions is lower still (there have to be >3 contiguous 
CE markings from the upstream queue). It's quoted below for your 
convenience.

I think we should also the following to this text (as pointed out 
recently by Koen):
     "On the plus side, misclassifying a CE-marked Classic packet 
delivers the congestion notification to the end-to-end transport without 
any Classic queuing delay. "


    Risk of reordering classic CE packets:  Having to classify all CE
       packets as L4S risks some classic CE packets arriving early, which
       is a form of reordering.  Reordering can cause the TCP sender to
       retransmit spuriously.  However, one or two packets delivered
       early does not cause any spurious retransmissions because the
       subsequent packets continue to move the cumulative acknowledgement
       boundary forwards.  Anyway, the risk of reordering would be low,
       because: i) it is quite unusual to experience more than one
       bottleneck queue on a path; ii) even then, reordering would only
       occur if there was simultaneous mixing of classic and L4S traffic,
       which would be more unlikely in an access link, which is where
       most bottlenecks are located; iii) even then, spurious
       retransmissions would only occur if a contiguous sequence of three
       or more classic CE packets from one bottleneck arrived at the
       next, which should in itself happen very rarely with a good AQM.
       The risk would be completely eliminated in AQMs that were
       transport-aware (but they should not need to be);


Bob

On 12/11/16 16:04, Bob Briscoe wrote:
> Mirja,
>
> Sorry, it's become rather hard to follow my replies, given sent in 
> pieces. I've tagged the questions and answers to make it clearer:
>
> On 12/11/16 12:53, Bob Briscoe wrote:
>> Mirja,
>>
>> The previous response only addressed your first question, 'cos I sent 
>> in haste ( I had to go offline to board the flight). Below I address 
>> the other questions.
>>
>> On 12/11/16 12:21, Bob Briscoe wrote:
>>> Mirja,
>>>
>>> It's great you've managed to find time to finish the implementation 
>>> - well done!
>>> Pity I didn't find time to reply sooner :O
>>> inline...
>>>
>>>
>>> On 31/10/16 12:00, Mirja Kühlewind wrote:
>>>> Hi Bob, hi Richard,
>>>>
>>>> I’ve submitted a new version of this draft with only minor changes. 
>>>> I finished my implementation but still have to do some testing. 
>>>> Current code is here:
>>>>
>>>> https://github.com/mirjak/linux-accecn
>>>>
>>>> This is really not tested carefully I but have right now some 
>>>> problems with my testing environment… anyway wanted to submit a new 
>>>> draft version before the deadline. However, given my current 
>>>> implementation is, as far as I can tell now, complete, I believe 
>>>> the spec is fins.
>>>>
>>>> I only have a few comments/questions regarding the fall-back rules 
>>>> we describe in the drafts (sec. 3.2.4):
>>>> *Q1 *- we don’t say anything about retransmitting the SYN. Should a 
>>>> retransmitted SYN try to negotiate AccECN or not, or are we relying 
>>>> on the classic ECN fall-back rules in this case (which would be 
>>>> clearing the ECN flags)?
>>> *A1 *- Good point - I was (we were?) thinking about the option being 
>>> blocked by a middlebox, but not the AccECN flags in the main header.
>>>
>>> We need to allow plenty of implementer choice here, but give a good 
>>> default. The default depends on how likely an AccECN SYN will be 
>>> dropped because of the AccECN flags. I think your tests [PAM paper] 
>>> found no drop due to these flags.
>>>
>>> So, here's some suggesting text:
>>>
>>> Measurement tests [PAM paper] so far have found that it is extremely 
>>> rate for middleboxes to drop a SYN just because all three ECN flags 
>>> are set (i.e. it is negotiating to use AccECN). Therefore, if the 
>>> sender of an initial AccECN SYN times out waiting for the SYN/ACK it 
>>> will more likely be due to congestion loss than middlebox 
>>> interference. This suggests the following strategy will maximize the 
>>> chances of using AccECN while minimizing delay.
>>>
>>> If the sender of an AccECN SYN times out before receiving the 
>>> SYN/ACK, the sender SHOULD attempt to negotiate the use of AccECN at 
>>> least one more time by continuing to set all three TCP ECN flags on 
>>> the first retransmitted SYN. If this first retransmission also fails 
>>> to be acknowledged, the sender SHOULD send subsequent 
>>> retransmissions of the SYN without any ECN flags set.
>>>
>>> This adds delay, but no more delay than normal, if the cause was 
>>> congestion. In the case that a middlebox drops an AccECN (or ECN) 
>>> SYN deliberately, this strategy will add delay, but current 
>>> measurements show this case is likely to be rare.
>>>
>>> Implementers MAY use other fall-back strategies if they
>>> are found to be more effective (e.g. attempting
>>> to retransmit an AccECN SYN more than once, (most appropriate during
>>> high levels of congestion); or falling back to classic ECN feedback
>>> rather than non-ECN).
> , or cached knowledge associated with the remote host.
>>>
>>> Nit in 3.2.4: s/tha/that/
>>>
>>> I believe there was a bug where the Linux connection-manager got 
>>> into a black-holing state if it didn't support the TFO option. Even 
>>> tho the bug was fixed, there are likely to be bugged Linux routers 
>>> out there. So we need to check the black hole doesn't apply to 
>>> AccECN SYNs as well. If it does, we will need to suggest restarting 
>>> a new connection as a fall-back. I'll check the details.
>>>
>>>
>>> Bob
>>>
>>>
>>>> *Q2* - What if we receive a second SYN with AccECN negotiation? We 
>>>> would probably send a SYNACK that negotiates AccECN but no Option, 
>>>> assuming that the SYNACK was lost, right? And then probably also go 
>>>> into a mode where we don’t send the option anymore..? We don’t say 
>>>> anything about this case in the draft.
>> *A2* - The trouble is that SYN/ACKs are just as likely to be lost due 
>> to congestion (e.g. found this in our L4S testing). But I agree that, 
>> in this case, I think send the SYN/ACK without the option, but try to 
>> include the option pretty soon afterwards.
>>
>> Rest of email will follow when I land...
>>
>>
>> Bob
>>
>>>> *Q3* - Also should we add a sentence that one could monitor the 
>>>> segments that carry an option and if it is much more likely that 
>>>> such a segment would be lost, then disable sending the option? Of 
>>>> current that only works for segments that carry data as well.
> *A3* Yes. 3.2.4 seems like the best place for that as well.
>>>> *Q4* - And finally we probably should to add an experimentation 
>>>> section, where we say that the question which fallbacks are 
>>>> actually needed must be investigated by experimentation. (Currently 
>>>> I only implemented clearing of the ECN flags when retransmitting a 
>>>> segment with the SYN flag set). Then we could also move any text we 
>>>> would like to keep from Appendix C into this section.
>
> *A4* - We have 1.3 for this: "Experiment Goals". We could add a 
> sentence saying most of the issues that need experimental verification 
> concern path traversal.
>>>> *Q5* - Also another side mark: I currently implemented AccECN and 
>>>> increase the respective counters but don’t use them of course. 
>>>> Maybe we should add one section in the draft that is directed to 
>>>> people that would like to use these counters of an existing 
>>>> implementation, e.g. adding a warning that counters might not 
>>>> increase even if AccECN is negotiation because options could be 
>>>> stripped, and that the CE packet counter could increase differently 
>>>> as it includes control packets without data and therefore usually 
>>>> both values should be checked… we say this all in the draft 
>>>> somewhere but maybe it be good to has this summarized in some kind 
>>>> of ‚usage‘ section…?
>
> *A5* Yes. Perhaps "AccECN Usage Examples"
>
> And this would be a good place to talk about behaviour that depends on 
> other parallel updates to ECN that are in progress (whether 
> experimental or PS), e.g.:
>
> ecn-fallback:
> Perhaps this (informative?) usage section could also repeat relevant 
> stuff from ecn-fallback that isn't specific to AccECN, but applies 
> generally to ECN TCP.
>
> generalized-ecn:
> This usage section would also be a good place to address open issue #3 
> (Appx C). But I'm not clear where to define the normative behaviour 
> concerning the interationc between ECT control packets and AccECN. It 
> would be really odd to talk about the details of AccECN counters in 
> generalized-ecn. But it is hard to talk about generalized ECN in the 
> AccECN draft, because it is not yet a WG draft, and we really don't 
> want to hold back AccECN.
>
> *More Nits**
> *In 3.3:
> s/intervene/intervenes/
>>>>
>>>> I guess we could prepare these changes (if any) and submit IETF 
>>>> Monday (if not today again) and ask for wglc in tcpm…?
>>>>
>>>> Mirja
>>>>
>>>>
>>>>
>>>>> Am 31.10.2016 um 12:21 schrieb [e-mail]:
>>>>>
>>>>>
>>>>> A new version of I-D, draft-ietf-tcpm-accurate-ecn-02.txt
>>>>> has been successfully submitted by Mirja Kühlewind and posted to the
>>>>> IETF repository.
>>>>>
>>>>> Name:        draft-ietf-tcpm-accurate-ecn
>>>>> Revision:    02
>>>>> Title:        More Accurate ECN Feedback in TCP
>>>>> Document date:    2016-10-31
>>>>> Group:        tcpm
>>>>> Pages:        37
>>>>> URL: 
>>>>> https://www.ietf.org/internet-drafts/draft-ietf-tcpm-accurate-ecn-02.txt 
>>>>>
>>>>> Status: 
>>>>> https://datatracker.ietf.org/doc/draft-ietf-tcpm-accurate-ecn/
>>>>> Htmlized: https://tools.ietf.org/html/draft-ietf-tcpm-accurate-ecn-02
>>>>> Diff: 
>>>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-accurate-ecn-02
>>>>>
>>>>> Abstract:
>>>>>    Explicit Congestion Notification (ECN) is a mechanism where 
>>>>> network
>>>>>    nodes can mark IP packets instead of dropping them to indicate
>>>>>    incipient congestion to the end-points.  Receivers with an ECN-
>>>>>    capable transport protocol feed back this information to the 
>>>>> sender.
>>>>>    ECN is specified for TCP in such a way that only one feedback 
>>>>> signal
>>>>>    can be transmitted per Round-Trip Time (RTT). Recently, new TCP
>>>>>    mechanisms like Congestion Exposure (ConEx) or Data Center TCP
>>>>>    (DCTCP) need more accurate ECN feedback information whenever more
>>>>>    than one marking is received in one RTT.  This document 
>>>>> specifies an
>>>>>    experimental scheme to provide more than one feedback signal 
>>>>> per RTT
>>>>>    in the TCP header.  Given TCP header space is scarce, it overloads
>>>>>    the three existing ECN-related flags in the TCP header and 
>>>>> provides
>>>>>    additional information in a new TCP option.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Please note that it may take a couple of minutes from the time of 
>>>>> submission
>>>>> until the htmlized version and diff are available at tools.ietf.org.
>>>>>
>>>>> The IETF Secretariat
>>>
>>
>
> -- 
> ________________________________________________________________
> Bob Briscoehttp://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/