Re: [conex] Fwd: Feedback on draft-ietf-conex-tcp-modifications-05

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

Hi Nandita,

thanks a lot for your review. Please see comments in-line.

> (feedback as individual contributor)
>
> No need to sugar coat: this draft needs lot more work. But happy to
> help to shape it to its final form.
>
> ---------
>
> Table of Contents
>
> * Section 2 is Sender side changes. I was looking for equivalent
> Receiver side changes, but there's no section for that. Should there
> be one?
There used to be receiver-side changes but as we move the accECN 
feedback to tcpm, no changes at the receiver are needed anymore. I added 
one sentence to explain this in the intro.

>
> * Section 3 My suggestion is to swap the ECN and loss detection
> sections, because loss detection methods are implicit and can be used
> today, while ECN requires... well ECN to be deployed.
yes, will do

>
> Introduction
>
> * At the end of Introduction lay out the organization of the remainder
> of the draft so a reader is informed of how the flow looks like.
I would say all the text is already there but I now added references to 
the respective section in the intro.

>
> * Need to set up the problem being addressed
> Jumping to Section 2 on Sender side modifications felt abrupt. What's
> missing is a setup of the problem that the draft is proposing TCP
> changes for. Can we place this problem setup either in the Intro. or a
> separate section in itself. An example of what might go into the
> problem set up is: Algorithms for a ConEx sender to keep track of byte
> wise congestion.
Isn't that given by the first paragraph: "This document describes the
    necessary modifications to use ConEx with the Transmission Control
    Protocol (TCP)."
In fact the whole intro is only explaining what to expect in the rest of 
the doc. I hope that the changes I now applied help to make the 
structure more clear (incl. references to the following section) ...

>
> Section 2. Sender-side modifications
>
> * "A ConEx sender MUST negotiate for both SACK and ECN.... Thus a
> ConEx SHOULD also implement SACK and ECN".
> The para appears incorrect to me. If you mandate a MUST for SACK/ECN
> negotiation, then shouldn't there be a MUST also for implementing SACK
> and ECN?
The point is that the ... you left out says "if available at the 
sender". Which means that if you have implemented SACK and ECN, you MUST 
use it. But if there are good reasons for you to implement ConEx but not 
SACK or ECN, you can still use ConEx. Howover, if you implement ConEx, 
you SHOULD also implemented SACK and ECN because otherwise it doesn't 
work that well.
So I think the text is correct. Should I re-phase it to make it more 
clear? Do you have a concrete proposal?

>
> * Pseudo code.
> Section 2 begs for pseudo code to succinctly describe the proposal.
> Else the text is unnecessarily wordy.
Sorry I don't see how to put pseudo code in this section because it only 
specifies all the MUSTs and SHOULDs but does not give any concrete 
algorithms. All detailed algorithms are in the next to sections. Do you 
have a proposal otherwise?

>
> * Section 2 ends abruptly. It sets up the problem and I was looking
> for more details, but I guess they are punted to the other sections in
> the draft.
Yes. I hope that is more clear in the intro now but there is also the 
last paragraph that basically says that all the details are given in the 
next section:
"The congestion accounting for each operation mode is described in the 
next section and the handling of the IPv6 bits itself in the subsequent 
section afterwards."
What else would you like to see?

>
> Section 3. Accounting congestion
>
> * "... ConEx marked either with the E bit or the L bit..."
> AFAICT this is the first occurrence of E and L bits, and hence should
> define them.
There used to be the reference to the CDO draft in the intro which i 
moved at some point to section 4. But you are right as I need the bits 
already here, I now moved it back into the intro.

>
> * Section 3 uses "outstanding bytes" often to describe the algorithms.
> On immediate reading it was confusing, because in TCP implementations
> outstanding bytes refers to the data that's been sent out but not
> ACKed yet.
Any suggestion how to change this? Or is it just you that confuses this?

>
> What you really mean by outstanding bytes here is a count of the
> remaining bytes that are yet to be ConEx marked with either ECN or
> loss bits. It's worthwhile having an explicitly and precisely efined
> term here.
The first paragraph says: "These counters hold the
    number of outstanding bytes that should be ConEx marked either with
    the E bit or the L bit in subsequent packets."
Don't you think that is defined well enough?

>
> Section 3.1
>
> * The algorithmic description of DeliveredData is laborious. Can you
> see if you can simplify the description. Also take a look at [PRR RFC]
> and see how DeliveredData is described there.
This description was taken from PRR but is more detailed. I would 
definitely prefer to have a detailed equation here than just a 
description as in RFC PPR.  I don't think it can be simplified. But I 
believe in case you actually sit there and implement ConEx it is less 
laborious. Or can you provide a concrete proposal how to describe this 
in a simpler way?

>
> * Is Section 3.1 the best place to describe DeliveredData?
> DeliveredData is trivial when there's no loss - it's just the number
> of bytes acked. So clearly the value of DeliveredData is when there
> are packet losses. So then shouldn't you be describing in the loss
> sesction and using that definition in the ECN section.
As we do not use DeliveredData in the loss section, why should we 
describe it there?

>
> This also goes back to an earlier comment I made that you should
> consider swapping the two placement of these two sections, 3.1 and
> 3.2.
>
> * For ease of reading and simplicity, please split up the equation for
> DeliveredData into the SACK and non-SACK case.
I've move the equation up and inserted more paragraph breaks in the 
text, but I'm not sure how you would like to change the equation itself?

>
> Section 3.1.2 Classic ECN support
>
> * ".... it will receive one full RTT of delayed ACKs with the ..."
> I don't remember exactly, but some implementations may disable delayed
> ACKs on receiving a CE mark. What's the significance of mentioning
> delayed ACKs here?
ack, removed 'delayed'.

>
> * Why not recommend (SHOULD?) to turn off delayed ACKs when rceiving
> CE marks. May be this belongs to another draft and not here?
It does not really help the problem that much to turn of delayed ACKs; 
plus you might not want to turn it oft if there is already congestion; 
it would be necessary to implement a more accurate ECN feedback though 
but that's an own draft.
Anyway, remember as we do not have a negotiation to use conex this 
document should be sender-side changes only.

>
> * The description of the more sophisticated heuristic to extract
> congestion notification at the end of Section 3.1.2 sounds half
> hearted to me. My suggestion: either describe it nicely and clearly
> with pseudo code etc., or give a high level idea here and ditch the
> details to an Appendix. At least that way the flow of the draft is
> maintained.
I don't really want to give pseudo code for this because than you have 
to introduce quite a lot state information. In fact our goal still is to 
name this option but not to encourage people to actually implement it 
and instead hopefully use a more accurate ECN feedback in future.

>
> Section 3.2 Loss Detection
>
> * Do retransmitted packets carry ConEx L bit or just the original data
> segments? Whatever the answer is, why?
The original data cannot carry the bit because at this point of time the 
packet was not lost yet...? So in most cases as the next packet you sent 
after detecting a loss is the retransmission and you what to send the 
ConEx signal as timely as possible, the retransmission will be L marked. 
But there is no need to bundle this. That's why it is not explicitly 
stated (anymore) because it just doesn't matter.
>
> Section 3.2.1 Without SACK Support
>
> * Isn't this the right place to discuss DeliveredData w/o SACK support?
Why? You don't need it here as we simply look at the size of the retransmit.
>
> Section 3.2.1 Without SACK support
>
> * General comment that's not sepcific to this section: LEC and LEG are
> very close in naming, but mean different things. Can we coose better
> names?
Yes I also though about it, but couldn't come up with a better name yet. 
Do you have a proposal?

>
> * Is there any implicit relation between LEC and LEG counters? Seems
> like there is, otherwise why do you say that LEG shoul be increased by
> LEC?
I don't really understand your question...?

>
> * It seems to me that you have a nice algorithm here, but sorry you
> totally lost me. My only suggestion would be to try and put the algo
> in a nice pseudo code.
Will think about it...

>
> Section 4
>
> * A lot of what appears in this section seems like should be in the
> sendder side changes.
Of course it is all sender side changes but section 2 just describes the 
specification with MUSTs and SHOULDS while section 3 and 4 give more 
details. Of course section 2 already says that all these things need to 
be done but on a high level.
You cannot move this section though because you need to explain LEG/CEG 
first which is done in section 3.
>
> Section 4.1
>
> * What's the reasoning behind: "If the CEG or LEG counter is negative,
> the respective counter SHOULD be reset to sero within one RTT after it
> was decreased..."
Because congestion is timely information which is outdated after one 
RTT. Do I need to add this reasoning here, because for me that was 
really obvious and it is more elaborated in section 6 as well...
>
> Section 4.2
>
> * Please clarify the relation between credit counter and the previous
> counters LEG/LEC? Are they independent?
yes independent. But i don't think this should be further explained here 
because you should rather read the abstract mechanism doc or auditing 
doc instead.
>
> * Could you expand more on how you arrived at: every fourth packet
> will allow teh respective number of credits in Slow Start..." I can
> see how it works. Is there a formulae connecting the Slow Start
> exponent and the the nth packet that needs to be marked?
yes and no; it's just because you double your window in Slow Start. So 
you have already halve the packets marked form the old window in the 
previous RTT and you have to marked halve the packet of the total 
increase in this RTT, which is one quarter of the window at the end of 
this RTT - thus every fourth packet. But there is not really a 
formula... do you think there is further explanation needed? Because if 
you take a little time to think about it, it easy to figure that out.

>
> * Mention how credits should be replenished in congestion avoidance phase.
That's the second paragraph:
"The number of credits sent should always equal the number of bytes in 
flight, as all packets could potentially get lost or congestion marked. 
Thus a ConEx sender should monitor the number of bytes in flight f. If f 
ever becomes larger than c, the ConEx sender SHOULD send new credits. 
Remember that c will be decreased if congestion occurs. "
That's simply true in Congestion Avoidance as well as in Slow Start. But 
in Slow Start this will usually lead to a (too) large number of credits 
sent therefore (if you want to take the risk to potentially but very 
rarely have sent to less credits) you can use the proposed algorithm in 
Slow Start.
I can make this point more clear if you think that's not clear enough.

>
> Section 6 Timeliness of the ConEx Signals
>
> * You discuss the event when receiving both ECN and loss signals. But
> how should the sender respond? Send ConEx signals for summation of
> both ECN/loss (I would think not) or choose the max?
I'm not sure I understand your question but you have to reflect all 
congestion feedback you get. To detect loss and get ECN feedback at the 
time is a valid case thus you have to increase both counters and sent E 
as well as L marks. What exactly was your question?

Thanks!
Mirja

>
> Editorial changes
>
> I have tons of editorial changes marked all over the draft - too many
> to spend time to cut+paste in this email. I'll just scan the sheets
> and send them to you.
>
> -------------------------------------------------------
>

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