Subject: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 2 Nov 2012 03:21:29 -0700

Hello,

I'm reading the draft and I still need more time to think about this, but I
have one question to proceed..

It seems to me that TLP requires FACK-based recovery logic.
if RFC6675 is used instead, I'm guessing TLP probably won't be so useful
since it cannot recover all lost packets in some situations.
AFAIK we don't have a concrete specification for FACK. Hence, I have a
little concern that we cannot think about detailed corner cases for this
approach.
Any thoughts on this?

Thanks,
-- 
Yoshifumi Nishida

---

From: Nandita Dukkipati <[email-masked]>
Date: Fri, 2 Nov 2012 19:33:24 +0530

You are right that TLP as specified requires FACK based recovery. FACK
is actually one of the most effective algorithms for loss recovery in
our experiments and it's worthwhile having (reviving?) a concrete
specification for FACK. Are there particular corner cases that you are
concerned about?

Nandita

On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida
<[email-masked]> wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 2 Nov 2012 10:12:00 -0700

> our experiments and it's worthwhile having (reviving?) a concrete
+1 on reviving FACK loss detection algorithm in "M. Mathis, J.
Mahdavi, "Forward Acknowledgement: Refining TCP Congestion Control,"
SIGCOMM 96, August 1996": trigger FR if the highest sack sequence >
dupthresh.

It's not very complicated and can be a revision to RFC6675? The sender
can fall back to current scheme if it detects high reordering based on
(D)SACK or TS. Linux by default uses this strategy (since 2006?) but
supports RFC6675 as an option. I experimented both on Google web
servers and FACK recovery is about 10% faster for connection
experiencing losses.

But Matt Mathis is not too interested in on reviving ancient proposals...

---

From: Yoshifumi Nishida <[email-masked]>
Date: Fri, 2 Nov 2012 10:58:00 -0700

Hi Nandita,

I don't have specific scenarios in my mind yet. But, I personally would
like to support the idea for having a spec of FACK. I think FACK is a
worthy idea for the efforts and we can eliminate some ambiguity from the
TLP draft.

On the other hand, I have another comment on the draft.
I'm assuming the draft is focusing on "probing" rather than "recovering".
So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can be
useful for this purpose, although I might miss something.

One tricky thing in TLP is you need to identify if packet loss is recovered
by only TLP. But, I guess there will be false positive cases in some
situations. If you retransmit small amount of data, I guess we can avoid
this and hence we can at least simplify the logic in the proposal.

Thanks,
--
Yoshifumi Nishida

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Sat, 3 Nov 2012 11:15:58 +0000

Hi Yoshifumi,

I agree that without using TS or SACK, probably the only way to differentiate between in some cases between the delayed original and the tlp packet would be to modify the size of the TLP.

However, i wonder if that complexity is really worthwhile. It would be much easier and efficient to enable TS and SACK on links prone to tail drops and reordering - and not only for a quicker tail loss recovery...

Best regards,
   Richard

Von meinem iPhone gesendet

Am 02.11.2012 um 13:58 schrieb "Yoshifumi Nishida" <[email-masked]<mailto:[email-masked]>>:

Hi Nandita,

I don't have specific scenarios in my mind yet. But, I personally would like to support the idea for having a spec of FACK. I think FACK is a worthy idea for the efforts and we can eliminate some ambiguity from the TLP draft.

On the other hand, I have another comment on the draft.
I'm assuming the draft is focusing on "probing" rather than "recovering".
So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can be useful for this purpose, although I might miss something.

One tricky thing in TLP is you need to identify if packet loss is recovered by only TLP. But, I guess there will be false positive cases in some situations. If you retransmit small amount of data, I guess we can avoid this and hence we can at least simplify the logic in the proposal.

Thanks,
--
Yoshifumi Nishida

On Fri, Nov 2, 2012 at 7:03 AM, Nandita Dukkipati <[email-masked]<mailto:[email-masked]>> wrote:

Nandita

On Fri, Nov 2, 2012 at 3:51 PM, Yoshifumi Nishida
<[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yuchung Cheng <[email-masked]>
Date: Sat, 3 Nov 2012 15:41:20 -0700

On Sat, Nov 3, 2012 at 4:15 AM, Scheffenegger, Richard <[email-masked]> wrote:
>
> Hi Yoshifumi,
>
> I agree that without using TS or SACK, probably the only way to
> differentiate between in some cases between the delayed original and the tlp
> packet would be to modify the size of the TLP.
>
> However, i wonder if that complexity is really worthwhile. It would be
> much easier and efficient to enable TS and SACK on links prone to tail drops
> and reordering - and not only for a quicker tail loss recovery...
>
> Best regards,
>    Richard
Both Yoshifumi and Richard have very good points. I am leaning toward
re-sending original last packet. The focus of TLP is latency on short
transfers experiencing losses. It's not probing nor converting timeout
to recovery etc. After all it's just retransmitting stuff earlier or
later.

1-byte probe eases the complexity of detecting single (>1 byte) packet
drop when DSACK or TS is not supported. But it costs one more RTT to
recover! that is detrimental for short transfer latency.

We are experimenting both ideas on Google Web servers to get more data.

> Am 02.11.2012 um 13:58 schrieb "Yoshifumi Nishida"
> <[email-masked]>:
>
> Hi Nandita,
>
> like to support the idea for having a spec of FACK. I think FACK is a worthy
> idea for the efforts and we can eliminate some ambiguity from the TLP draft.
>
> So, I'm wondering that even retransmitting small bytes (e.g. 1 byte) can
> be useful for this purpose, although I might miss something.
>
> One tricky thing in TLP is you need to identify if packet loss is
> recovered by only TLP. But, I guess there will be false positive cases in
> some situations. If you retransmit small amount of data, I guess we can
> avoid this and hence we can at least simplify the logic in the proposal.
>
> Thanks,
> --
> Yoshifumi Nishida
>
>
>

---

From: Nandita Dukkipati <[email-masked]>
Date: Tue, 6 Nov 2012 19:58:59 +0530

> I'm assuming the draft is focusing on "probing" rather than "recovering".
Yes, probing is one of the main goals - to be able to elicit some ACKs from
the receiver in the event of long silence periods. If the ACKs trigger
recovery, that's good.

> be useful for this purpose, although I might miss something.

You are spot on! In fact, this is one of the experiments we'll be trying
out in next few days. I have checked that receiving SACK for 1-byte
retransmission can also trigger FACK based fast recovery (or early
retransmit depending on FlightSize) at least in Linux, so that's good.

> avoid this and hence we can at least simplify the logic in the proposal.

Correct, this logic can be greatly simplified if we limit TLP
retransmissions to 1-byte.

As Yuchung also noted in his response, we are experimenting with both
approaches: 1) loss detection using the dupack counting that the draft
outlines; 2) limiting TLP retransmissions to 1-byte, in which case there's
no extra logic needed to identify if TLP masked loss.

An argument against 2) is that for short flows (extreme case FlightSize==1)
it unnecessarily takes one extra RTT to retrans. the remainder of the
segment. But I think the critical part is saving an RTO versus saving an
RTT.

Thanks!
Nandita

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 6 Nov 2012 18:26:42 +0000

Hi Nandita, Yuchung, Matt,

just to keep a record of the discussion around FACK on list.

TLP refers to FACK for loss recovery. Matt mentioned on the microphone, that RFC6675 does address FACK. Following the session, there were some discussions around that comment.

Even when RFC6675 (SACK) is combined with RFC5827 (Early Retransmit), there are scenarios - and I think the more interesting ones - that are NOT triggering loss recovery.

RFC6675 has this text:

(2) If DupAcks < DupThresh but IsLost (HighACK + 1) returns true --
       indicating at least three segments have arrived above the current
       cumulative acknowledgment point, which is taken to indicate loss
       -- go to step (4). [loss recovery]

IsLost (SeqNum):

      This routine returns whether the given sequence number is
      considered to be lost.  The routine returns true when either
      DupThresh discontiguous SACKed sequences have arrived above
      'SeqNum' or more than (DupThresh - 1) * SMSS bytes with sequence
      numbers greater than 'SeqNum' have been SACKed.  Otherwise, the
      routine returns false.

RFC5827 has this text:

(2.a) The amount of outstanding data (ownd) -- data sent but not yet
         acknowledged -- is less than 4*SMSS bytes (as defined in
         [RFC5681<http://tools.ietf.org/html/rfc5681>]).
[..]

(2.b) There is either no unsent data ready for transmission at the

         sender, or the advertised receive window does not permit new

         segments to be transmitted.
[..]

When conditions (2.a) and (2.b) hold and a TCP connection does

   support SACK or SCTP is in use, Early Retransmit MUST be used only

   when "ownd - SMSS" bytes have been SACKed.

With TLP, and a tail drop of a higher number of packets, loss recovery is not entered, based on this.

In the example given on the slides: 1 2 3 4 5 x x x x x, the number of outstanding segments (5) is larger than where Early Retransmit allows reducing DupThresh. TLP resending segment 10 would trigger a single SACK packet, but that wouldn't suffice to enter loss recovery.

So, the draft would need to either define FACK, or have some text that after TLP sends out a "rescue" retransmission, DupThresh has to be reduced to 1 temporarily, so that RFC6675 loss recovery triggers.

Best regards,

Richard Scheffenegger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Nandita Dukkipati
Sent: Dienstag, 06. November 2012 15:29
To: Yoshifumi Nishida
Cc: [email-masked]
Subject: Re: [tcpm] q about draft-dukkipati-tcpm-tcp-loss-probe-00

On Fri, Nov 2, 2012 at 11:28 PM, Yoshifumi Nishida <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nandita,

On the other hand, I have another comment on the draft.
I'm assuming the draft is focusing on "probing" rather than "recovering".
Yes, probing is one of the main goals - to be able to elicit some ACKs from the receiver in the event of long silence periods. If the ACKs trigger recovery, that's good.

You are spot on! In fact, this is one of the experiments we'll be trying out in next few days. I have checked that receiving SACK for 1-byte retransmission can also trigger FACK based fast recovery (or early retransmit depending on FlightSize) at least in Linux, so that's good.

Correct, this logic can be greatly simplified if we limit TLP retransmissions to 1-byte.

As Yuchung also noted in his response, we are experimenting with both approaches: 1) loss detection using the dupack counting that the draft outlines; 2) limiting TLP retransmissions to 1-byte, in which case there's no extra logic needed to identify if TLP masked loss.

An argument against 2) is that for short flows (extreme case FlightSize==1) it unnecessarily takes one extra RTT to retrans. the remainder of the segment. But I think the critical part is saving an RTO versus saving an RTT.

Thanks!
Nandita

Thanks,
--
Yoshifumi Nishida

Nandita