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

[Mirja Kuehlewind <[e-mail]>]

Hi Jana,

thank you for your feedback. We just uploaded a new version for addressing 
quickly the last two ToDo:

1. Sending Credits
   -> A ConEx sender should maintain flightsize number of packets as credits 
	(in CA)
2. Loss of ConEx infos
   -> A ConEx sender should detect this case and send further credits

But there are actually still some open questions mainly regarding the credits:

1) What's the right reaction if ConEx markings get lost?
2) How to detect false positives of the audit at the sender?
3) How to incentives a sender to send right markings at the right time (e.g. 
to not send credits instead of L/E markings)?

I'm going to send separate emails now to further explain these points and 
hopefully discuss these questions on the list.

Mirja


On Friday 31 May 2013 19:55:06 Janardhan Iyengar wrote:
> Mirja, Richard, all
>
> A bit late, I'm sending along my review
> of draft-ietf-conex-tcp-modifications-02. I noticed that -03 came along
> while I was reading the -02 version; I'm also happy to review later
> versions.
>
> Overall, the text could use some tightening up. Some text may need to be
> rewritten (I've suggested some below), and some could be eliminated
> altogether. My major feedback at this time would be that the draft should
> focus on mechanisms that are clear and are to be specified (such as LEG and
> CEG counts, for example). Other mechanisms that are either nascent or are
> not yet fully specified ought to be left out from this document (such as
> the more accurate ECN marking). More specific details follow.
>
> 1. Introduction:
> - "ConEx is a ...": cite RFC 6789. For someone who hits this draft, it is
> not clear where to go to find more about ConEx itself.
> - End paragraph after "use ConEx with the Transmission Control Protocol
> (TCP)."
>
> - Suggested restructuring:
>   + Move last paragraph "ConEx is currently/will be defined as an
> destination option for IPv6..." up here to the beginning of the second
> paragraph.
>   + Continue paragraph with "The ConEx signal is based on loss or ECN marks
> ..."
>   + Modify "loss or ECN marks" in the above sentence to "Explicit
> Congestion Notification (ECN) marks".
>
> - Suggested rewording for paragraph "With standard TCP ...":
> "This document describes mechanisms for TCP both with and without the
> Selective Acknowledgment (SACK) extension [RFC2018]. However, ConEx
> benefits from more accurate information about the number of packets dropped
> in the network. We therefore recommend using the SACK extension when using
> TCP with ConEx."
>
> - Modify: "Explicit Congestion Notification (ECN) is defined in such a way
> ..." to "ECN is defined in such a way ..."
>
> - 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."
>
>
> 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.
> - Using "SACK-accECN-Conex" instead of "Full-Conex" seems better
> descriptive.
> - "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. Perhaps cite the
> v6 options draft here without specifying here what a Conex sender MUST do.
> - "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.
>
>
> 3: Accounting Congestion:
> - The writing in this section can be cleaned up. For instance, "... is
> explained in the next section." should specify the section number.
> - "A TCP sender SHOULD account congestion byte-wise (and not packet-wise)
> ...": Cite draft-ietf-tsvwg-byte-pkt-congest.
> - "The subtraction of bytes which have been ConEx marked from both counters
> is explained in the next section.": What does "subtraction of bytes" mean?
> - "If equal sized packets ...": This sentence needs to be rewritten.
> Difficult to read and follow.
> - "If a sender sends different sized packets ...": difficult to follow as
> well. I understand what it says, but it needs to be rewritten to be clear.
> - "ECN is an IP/TCP mechanism ...": cite RFC3168.
> - "A receiver can support the accurate ECN feedback scheme ...": cite. It
> may be better to structure
> - "Note the change in in the SACK information can also be negative if the
> number of acknowledged bytes increases.": Not clear. Do you mean to say if
> the number of acked bytes decreases?
> - What are the variables is_after_dup and num_dup in the DeliveredData
> expression? Please describe them before the equation or immediately after.
>
> 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?
>
> 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.
>
> - jana



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------