Re: [conex] Friendly Reminder: ConEx TCP mods

[Mirja Kühlewind <[e-mail]>]

Hi Bob,

thanks!

See below for comments

> 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.

I kept this in the main document (also because this otherwise would be big rewrite)
but now it's stating at the beginning that simply retransmissions can be marked.
However, from my point of view the proposed algorithms are not very complicated 
(to implement) and improve the accuracy. As this document in fact provides 
implementation guidelines, I'd rather encourage people to implement these 
algorithms (and experiment with them) than indication this as clearly optional 
(by moving it in the appendix). If experimentation would show that these 
algorithms basically never become active, they could simply be removed.

Further spurious retransmission detection means that you detect that you have 
send unnecessary retransmission and therefore can re-do your congestion window 
reduction. However, it cannot take back any sent retransmission and therefore 
also not any unnecessary sent ConEx markings.

>
> 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.

For me the text was inline with the ConEx destopt doc, however I rephrased it to 
make it more clear.

It makes sense that you might use these packets to send out-standing L or E 
marks, however as you never get any feedback for these packet, you'll never send 
ConEx marking if any of these packet experience congestion. A network node that 
estimates the congestion level on ConEx might therefore underestimate. That's 
why you don't always want to mark them.

The idea of this document was to give very clear instruction when to mark and 
when not to mark. Now it also says
"Only if no congestion feedback information is
       (currently) available, the X flag SHOULD be zero, such as for
       control packets on a connection that has not sent any (user)
       data for some time e.g., sending only pure ACKs which are
       not carrying any payload."
where 'for some time' is now undefined. I don't think I'm able to put a concrete 
time interval in there. Therefore I just leave it as it is now...

> 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.

I don't think that the current proposal is a big issue, as you only have to send 
one full window of credits once (and then only refill if needed). Further with 
Slow Start you probabbly should anyway send this amount of credits at the 
beginning. Moreover, even if you increase you sending rate very carefully or 
even not at all, competing traffic might be more aggressive and cause high 
(instantaneous) congestion for all flow on the path (especially if e.g. a AQM as 
for DCTCP is used). Thus you never can be use that you packets might not see 
congestion, even if you are very carefully.

I re-rewrote this again but added a your paragraph on experimentation at the 
end. However, I don't really believe that a less aggressive congestion control 
should send less credits because competing, aggressive traffic might cause 
losses and markings of your packets as well.

Further I removed most of the normative language here because these are mostly 
implementation proposals while the normative language itself is already in the 
destopt doc.

>
> 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.

So no... that's the point where it really would be nice to have an audit 
document. The point is that if you have no credit state anymore and there are 
only a few congestion marks/losses, the audit should also only penalize slightly 
(it should definitely not drop all packets). So it's easy to mistake this as 
additional congestion.

Of course, you build up (a few) new credits for the dropped packets but that 
likely will not cover your congestion risk and you might get penalized over and 
over again.

Note that the recommendation is to re-set state after LOSSES in two subsequent 
RTTs. Usually if loss occurs due to congestion, in case of dropTail the 
congestion should be resolved after the window reduction; in case of AQM (using 
drop) the drop probably should really be low enough to avoid losses in the next 
RTT when the congestion is in fact already resolved.

However, I'm not sure what to do here, so I slightly rephrased to
"A ConEx sender might reset the credit counter CSC to
         zero if losses occur in subsequent RTTs (assuming that the sending
         rate was correctly reduced based on the received congestion signal and
	using a conservatively large RTT estimation)."

This again makes a less clear recommendation but I guess that the reason why 
this is experimental.

>
> 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.

Yes, makes sense to me. That's where we do need experimentation. MAY is probably 
right.

>
> 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).

Thanks! Extended your last paragraph slight to make this (hopefully) easier to 
understand.

However this does not cover that traditionally congestion control only react 
once per RTT. That means an attacker could send additional congestion 
notification in each RTT. However, this is the same 'penalty' as if the classic 
ECN is used, therefore I thought it's okay to not mention this explicitly here...?


I've just submitted a new version. If you or Richard do not agree to any of the 
changes, I can also submit another version if needed, or in case of minor edit 
apply changes after the IESG review.

Thanks again for the feedback and your edit pass!!!

Mirja



>
>
> 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
>

-- 
------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Communication Systems Group
Institute TIK, ETH Zürich
Gloriastrasse 35, 8092 Zürich, Switzerland

Room ETZ G93
phone: [phone]
email: [e-mail]
------------------------------------------