Re: [conex] Friendly Reminder: ConEx TCP mods

[Bob Briscoe <[e-mail]>]

Mirja, Richard,

I've written my review comments into the XML. 
Sorry I didn't get this done earlier.

.xml .txt and a diff from draft-07 are here:
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-bb.xml>
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-bb.txt>
<http://bobbriscoe.net/projects/conex/draft-ietf-conex-tcp-modifications-07-DIFF-07-bb.html>


* I've put all the editorial suggestions (mostly 
english grammar) directly into the XML.
* I've made some changes I thought would be 
non-controversial directly in the text.
   Some involve moving paragraphs into sections that seemed more relevant.
* I've added comments as <cref> elements within the XML.
   These appear as footnotes, which you can turn off with <?rfc comments="no"?>

Feel free to reject any changes you don't like.

My overarching suggestion is that, if you want to 
keep any algorithm that adds incremental 
precision, put it in an appendix. Then the base 
document will be really simple.

I've added all my most significant concerns in my 
<cref> comments, rather than changing the text. I've summarised them here:

1) ConEx Loss marking: Just mark retransmissions. Simple.
    Rationale: TCP never retransmits less data than is lost.
    Any attempt to identify lost bytes more 
accurately or with less delay than the universe 
of TCP researchers and developers over the last 
two decades seems rather obsessive-compulsive.
    I know this seems harsh, but... if you want 
to keep the algo you've written, pls shift it to 
an appendix. But I would strongly urge removal.

2) The text in destopt says that the X flag will 
only be turned off "...if no congestion feedback 
is (currently) available e.g. in TCP if one 
endpoint has been receiving data but sending 
nothing but pure ACKs (no user data) for some time."
    draft-07 still says X is turned off if the 
packet in question has no payload, which I thought we agreed was wrong.

3) I've added a para saying that experimentation 
in credit algorithms is encouraged, and the ones 
given are mainly to be concrete.
    Nonetheless, I think the ones given need to 
be stated as absolute worst-case. They allow for 
the /absolute/ worst case, rather than the 
/likely/ worst case. E.g. the worst case during 
congestion avoidance is taken as "all packets in 
flight might suddenly be dropped".
    I know you're trying to say something 
concrete, so I suggest we keep these suggestions 
but make it clear that they cover the absolute worst-case.

4) The suggested test to detect a re-route onto 
an audit function with no flow state (i.e. at 
least a loss in two consecutive RTTs) is surely far too over-sensitive.
    Actually, I think no specific detection of 
this event is needed. I believe an audit function 
would drop a significant proportion of packets, 
but in the next round the normal rules you've 
specified will cause the sender to replenish the 
credit while responding to these losses. Perhaps I'm wrong though.

5) IMO, resetting negative balance after one RTT 
ought to be a MAY, not a SHOULD. I think we 
should care more about simplicity than precision.

I also added some security considerations text 
you might want to use (and I suggested moving the 
existing para under security considerations to 
Classic ECN Support, because it was about 
protocol safety during heavy congestion, not security against attackers).


Bob

At 10:08 07/03/2015, Bob Briscoe wrote:
>Mirja,
>
>Starting this now...
>
>Sorry I've delayed it until just before the IETF 
>deadline - BT and European project guff has just taken over my life since xmas.
>
>
>Bob
>
>At 19:12 03/02/2015, Mirja Kühlewind wrote:
>>Hi Bob!
>>
>>Can you please, please do the ConEx TCP mods review...? Please!
>>
>>Thanks,
>>Mirja
>
>________________________________________________________________
>Bob Briscoe,                                                  BT

________________________________________________________________
Bob Briscoe,                                                  BT