Re: [conex] Review of draft-ietf-conex-tcp-modifications-02

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

Hi Jana,

I'm incorporating your feedback at the moment. I commet on those things below, 
I did not take over as suggest. (That means the other things I removed in 
this mail as integrated as proposed). See below...

> - This paragraph about more information than ECN seems unnecessarily
> detailed. One sentence ought to be enough. Something like: "In addition to
> standard ECN and SACK feedback, an extension described in [
> draft-kuehlewind-conex-accurate-ecn] shows how more accurate ECN feedback,
> especially useful in the case of multiple markings within the same
> roundtrip time (RTT),  can be obtained."
I wanted to have the statement a little stronger, basically saying that ConEx 
is only with the more accurate ECN really usable. I changed the paragraph to 
the following text: 
"While loss-based congestion feedback should be minimized, ECN could actually 
provide more fine-grained feedback information. ConEx-based traffic 
measurement or management mechanisms would benefit from this. Unfortunately 
the current ECN does not reflect multiple congestion markings which occur 
within the same Round-Trip Time (RTT). A more accurate feedback extension to 
ECN is defined in a separate document [draft-kuehlewind-tcpm-accurate-ecn],       
as this is also useful for other mechanisms."

> 2: Sender-side Modifications:
> - "MUST negotiate for both SACK and ECN or the more accurate ECN feedback
> ..." : This strikes me as an odd MUST. SHOULD seems adequate.
We really wanted to have a MUST here, as we want (modern) system that 
implement ConEx to also implement SACK and ECN. Only because they try to 
negotiate, it does mean, that the other end will support it though. We could 
discuss that we want a "MUST negotiate for SACK" and "SHOULD negotiate for 
ECN" because SACK really helps to increase the accuracy. But I actually see 
no reason to only have a SHOULD for ECN.

> - "A ConEx sender MUST expose congestion to the network...": A compliant
> Conex sender has to follow a Conex spec for exposing congestion; that can
> be assumed here, without having a MUST in this document. 
I changed this to "A ConEx sender MUST expose all congestion information..." 
because that was the idea. If you decide to use ConEx, of course, you are 
planning send some ConEx markings from time to time, but actually the point 
is that you have to reflect ALL congestion information. Does this make more 
sense for you?
> Perhaps cite the 
> v6 options draft here without specifying here what a Conex sender MUST do.
Sorry, don't get this...?

> - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise)":
> Cite draft-ietf-tsvwg-byte-pkt-congest or justify otherwise.
> - "As network congestion is usually byte-congestion ...": Is this really
> the case? Cite.
I cited draft-ietf-tsvwg-byte-pkt-congest for the lower bullet point. But the 
reasoning for the upper point is mainly, that this document must specify one 
of the two ways, and we decided to handle the information byte-wise because 
that's how there are usually available in TCP (ack'ed bytes). Do I need to 
reason this?

> 3.1.2: Classic ECN Support:
> - It is non-trivial for a sender to determine when delayed acks will be
> sent by the receiver, in particular with bidirectional data transfer. I
> would be careful about suggesting such heuristics without getting into
> details. Is this "Advanced Compatibility" really practical or necessary?
This would be a sender-only change to get more accurate ECN information. Of 
course its complex and there is still a risk of missing congestion 
information, but we decided to describe this option here, as ConEx 
with 'classic' ECN is hardly usable.

>
> 3.2: Loss detection with/without SACK:
> - "assuming equal sized segments such that the retransmitted packet will
> have the same number of header as the original ones." You cannot make this
> assumption. There are commonly used stacks that will retransmit differently
> sized segments, and even combine retransmitted bytes with new bytes within
> a segment. This assumption is not critical, and so I would suggest dropping
> it from the text.
This should say, that the described solution can only be used under the 
assumption that packets are equally sized (which is at least true for e.g. 
file transfers with full IP packets). I added some more text in the 
introduction part of section 3 'Congestion Accounting' to explain that the 
number of (lost/marked) packets needs to be estimated otherwise:
"Otherwise if this is not the case and a sender sends different sized packets 
(with unequally distributed packet sizes), the sender needs to memorize or 
estimate the number of ECN-marked or lost packets. A sender might be able to 
reconstruct the number of packets and thus the header bytes if the packet 
sizes of the last RTT are known. Otherwise if no additional information is 
available the worst case number of headers should be estimated in a 
conservative way based on a minimum packet size (of all packets sent in the 
last RTT). If the number of ConEx marked packets is smaller (or larger) than 
the estimated number of ECN-marked or lost packets, the additional header 
bytes should the added to (or can be subtracted from) the respective 
counter."
Does this help?

Thanks a lot for the review!
Mirja