Subject: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-loss-probe-01.txt

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 12 Mar 2013 12:46:04 +0000

Hi,

editorial: The enumerated list after "Timeouts can occur in a number of situations, such as the following:" could use "hanging" indentation to make the numbering stand out (or use a numbered list with format (%d) ). (As a personal taste, I'd also have an empty line between the one sentence for the bullet description, and the more detailed explanation).

The numeric data points on page 4 could be put into an ascii art, or a formatted table, instead of free flowing text. Albeit, I wonder if some of these paragraphs shouldn't be better moved to an appendix, if the draft is adopted.

Regarding this statement:

   TLP MUST NOT be used for non-SACK connections.  SACK feedback allows
   senders to use the algorithm described in section 3 to infer whether
   any segments were lost.

When a sender has some way of discriminating between the TLP packet and the regular packet (ie. use of the TS option, with the TLP carrying a different TS than the original packet; F-RTO like discrimination can work out which packet triggered the ACK), TLP should be applicable to non-SACK sessions as well. Perhaps this working can be relaxed in that way. If so, then section 3 need some text regarding TS-based (F-RTO like) recovered loss detection.
OTOH: Encouraging the universal adoption of SACK, and not making enhanced features like this available to non-SACK, might not be that bad an idea anyhow.

(3) When PTO fires:

   (a) If a new previously unsent segment exists:

Is it deliberate, that this might sent a packet beyond rwin? (If so, that may be stated explicitly in the text beneath)

Thanks for adding the FACK recovery section!

One minor nit-pick:

If (SND.FACK - SND.UNA) > dupack threshold:
     -> Invoke Fast Retransmit and Fast Recovery.

Dupack threshold is usually stated in packets, while Snd.fack/snd.una is (usually) in bytes. For byte-oriented stacks, the clause might be better stated as:

If (SND.FACK - SND.UNA) > ((dupack threshold - 1)*MSS + 1):
     -> Invoke Fast Retransmit and Fast Recovery.

This will work for most instances, where one (the last) packet is of size smaller than MSS... (hat tip to Alex Zimmermann).

so it should enter fast recovery using the
   proportional rate reduction algorithm [IMC11PRR].

I think, that sentence can end after "enter fast recovery". The specifics how the sender performs fast recovery should be regarded out of scope of this doc...

Nit: an RTO. / a RTO.

Nit: insequence ACKs / in-sequence ACKs

Overall, I still think this is a very valuable mechanism and the document is very well written, giving a lot of relevant references.

Best regards,

Richard Scheffenegger

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 12 Mar 2013 15:34:38 +0000

To follow up on my comments on the microphone:

I think the special case when both PTO and RTO timer fire in the same cycle need to be documented... And some more text regarding the exact interaction with RTOrestart (where setting PTO=RTO will not necessarily cause PTO fire before RTO, I would expect) would be good.

I think I heared Jana to comment that if the cwnd is large but the sender is application limited, to proactively resend on the remaining, incoming ACKs (in order to not lose the ACK clock). But I'd like a more complete statement if that really is what was meant.

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scheffenegger, Richard
> Sent: Dienstag, 12. März 2013 13:46
> To: Nandita Dukkipati; [email-masked]
> Subject: [tcpm] New Version Notification for draft-dukkipati-tcpm-tcp-
> loss-probe-01.txt
> 
> 
> Hi,
> 
> editorial: The enumerated list after "Timeouts can occur in a number of
> situations, such as the following:" could use "hanging" indentation to
> make the numbering stand out (or use a numbered list with format (%d) ).
> (As a personal taste, I'd also have an empty line between the one sentence
> for the bullet description, and the more detailed explanation).
> 
> The numeric data points on page 4 could be put into an ascii art, or a
> formatted table, instead of free flowing text. Albeit, I wonder if some of
> these paragraphs shouldn't be better moved to an appendix, if the draft is
> adopted.
> 
> 
> 
> When a sender has some way of discriminating between the TLP packet and
> the regular packet (ie. use of the TS option, with the TLP carrying a
> different TS than the original packet; F-RTO like discrimination can work
> out which packet triggered the ACK), TLP should be applicable to non-SACK
> sessions as well. Perhaps this working can be relaxed in that way. If so,
> then section 3 need some text regarding TS-based (F-RTO like) recovered
> loss detection.
> OTOH: Encouraging the universal adoption of SACK, and not making enhanced
> features like this available to non-SACK, might not be that bad an idea
> anyhow.
> 
> 
> 
> (3) When PTO fires:
> 
> Is it deliberate, that this might sent a packet beyond rwin? (If so, that
> may be stated explicitly in the text beneath)
> 
> 
> 
> Dupack threshold is usually stated in packets, while Snd.fack/snd.una is
> (usually) in bytes. For byte-oriented stacks, the clause might be better
> stated as:
> 
> This will work for most instances, where one (the last) packet is of size
> smaller than MSS... (hat tip to Alex Zimmermann).
> 
> 
> I think, that sentence can end after "enter fast recovery". The specifics
> how the sender performs fast recovery should be regarded out of scope of
> this doc...
> 
> 
> 
> Nit: an RTO. / a RTO.
> 
> Overall, I still think this is a very valuable mechanism and the document
> is very well written, giving a lot of relevant references.
> 
> 
> Best regards,
> 
> Richard Scheffenegger
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 12 Mar 2013 23:17:28 +0100

> editorial: The enumerated list after "Timeouts can occur in a 
> number of situations, such as the following:" could use 
> "hanging" indentation to make the numbering stand out (or use 
> a numbered list with format (%d) ). (As a personal taste, I'd 
> also have an empty line between the one sentence for the 
> bullet description, and the more detailed explanation).

Some remarks, with chair hat off:

I also had difficulties parsing some description in the current draft, in particular Section 3.1, page 10. Apparently, two lists intersect without idention, both using (a)...

> Dupack threshold is usually stated in packets, while 
> Snd.fack/snd.una is (usually) in bytes. For byte-oriented 
> stacks, the clause might be better stated as:
> 
> This will work for most instances, where one (the last) 
> packet is of size smaller than MSS... (hat tip to Alex Zimmermann).

I don't think that this is a nit only. When reading this document, I indeed wondered how a byte-based stack would implement TLP.

In addition, I also wondered whether the TLP loss detection algorithm is indeed robust to packet reordering, in particular "stange" loss/reordering patterns. To be honest, I haven't thought of this in detail. But it would be certainly important to understand if the loss detection heuristic could fail in certain corner cases.

Michael

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 13 Mar 2013 11:08:45 -0700

> In addition, I also wondered whether the TLP loss detection algorithm is indeed robust to packet reordering, in particular "stange" loss/reordering patterns. To be honest, I haven't thought of this…
can you give an example of the reordering problem you have in mind?