Subject: [Tsvwg] WGLC on draft-allman-tcp-early-rexmt-03

From: Allison Mankin <[email-masked]>
Date: Tue, 03 Feb 2004 20:48:16 -0800

This begins a working group last call for the new revision of
the Early Retranmsit i-d (draft-allman-tcp-early-rexmt-03.txt) 
that came out in December.  It has been discussed throughout its
life in TSVWG, and the authors and we think it can be completed 
here rather than moved to the coming TCPM working group.

The WGLC is for Experimental RFC status.  Comments should be
made by February 17, 2004.

Your TSVWG Chairs

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 20 Feb 2004 14:42:58 +0100

Better late than never ...

I think this I-D should go forward. It proposes a useful algorithm that is well specified.

Comments:
---------
- I think you should explicitly say that conditions 2.a and 2.b, the calculation of ER_thresh, and hence the decision to fast retransmit, or not, should be executed each time a DUPACK arrives.

- I think you should say something about connections that have disabled Nagle's algorithm. Do they get to use the ER algorithm, too? 

Minor editing nits:
-------------------
- "a retransmission timer fires" > "a retransmission timer expires"

- "three duplicate ACKs arrive at the sender [Jac88,RFC2581]."
You should remove "Jac88" since the FR algorithm was introduced by V. Jacobson later. The reference to RFC2581 should be sufficient.

- I would prefer not to see an explicit reference to the RTO minimum of 1 second. RFCs live a long life, and things like the RTO minimum can change in the future. [I hope it will change. The idea of having a fixed value as the RTO minimum is broken, but we don't need to have this discussion here ... :-)]

- "in terms of bytes" > "in terms of octets"
I actually don't have a strong opinion on this, but at least that would make it consistent with existing RFCs on TCP.

- "the connection does support SACK Fast retransmit May be used"
  "the connection does support SACK, Fast retransmit May be used"

- "when ownd - SMSS bytes" > "when (ownd - SMSS) bytes"

///Reiner

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: Mark Allman <[email-masked]>
Date: Fri, 20 Feb 2004 09:02:59 -0500

Reiner-

Good comments, all.  Thanks!  I'll work them into a new rev.

>   I think you should say something about connections that have
>   disabled Nagle's algorithm. Do they get to use the ER algorithm,
>   too?

Hm.  Good catch.

But, what to do?  On the one hand, one could argue that avoiding the
hefty RTO timer is good for these connections because they are likely
highly interactive.  On the other hand, they may well have plenty of
outstanding packets to trip fast retransmit and not need early
retransmit.  And, further, it is difficult to easily assess whether they
have enough outstanding data to trigger fast retransmit.  In general, a
better test for ER is whether the connection has more than 3 packets
outstanding.  But, we fudge that based on the number of bytes since TCP
works in terms of bytes and would have to keep more (rich) state if it
were to track the number of packets outstanding.

I guess my inclination is to punt and say you can't use ER when Nagle is
enabled.  If a connection has enough data in flight to make the
ER_thresh ((ownd/SMSS) - 1) calculation meaningful and is using Nagle
than likely there is enough data in flight to trigger fast retransmit
(or, Nagle is being used spuriously).

Does that sound reasonable to folks?

Thanks!

allman

--
Mark Allman -- ICIR -- http://www.icir.org/mallman/

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Feb 2004 08:11:37 -0800

> were to track the number of packets outstanding.

That sounds like an invitation for feature interaction. It's never 
possible to know the number of packets TCP actually sends from the 
number of bytes outstanding, Nagle on or off.

What happens when it's 1-off? or more? presumably it errs on the side of 
caution, and does nothing?

In that case, at what point can a TCP implementation _know_ it can act 
if it doesn't keep track of the actual packets sent?

Joe

---

From: Mark Allman <[email-masked]>
Date: Fri, 20 Feb 2004 11:19:05 -0500

> > In general, a better test for ER is whether the connection has more
> > than 3 packets outstanding.  But, we fudge that based on the number
> > of bytes since TCP works in terms of bytes and would have to keep
> > more (rich) state if it were to track the number of packets
> > outstanding.
> 

Right.  I think we're agreeing here.  I was terse this morning.  Let me
try again... We *could* require a TCP that wants to use ER to try to
maintain a count of the number of packets in the network.  In most
cases, it's not that hard to keep enough state to determine this.  But,
we can all draw up cases when it is not so easy (retransmits that do not
fall along the exact packet boundaries of the original transmissions
come to mind).  In some sense, this would be the ideal for ER.  On the
other hand, that's a whole lot of work and probably not worth the
payoff.  And, as you note -- could we cause interactions that we do not
forsee and could be ugly.

A path that sounds good to me is to say if you use Nagle then you can't
use ER because assessing the number of packets in the network is
non-trivial.  And, we might note that if someone wants to hash out a
scheme to use ER with Nagle then that is fine as future work.

Is that a reasonable path forward?

Thanks!

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Feb 2004 08:23:14 -0800

> Is that a reasonable path forward?

I'm equally worried about ER without Nagle, though. I.e., the question is:
	- can you _ever_ get away with not counting actual packets sent?

Joe
...

---

From: Mark Allman <[email-masked]>
Date: Fri, 20 Feb 2004 11:29:28 -0500

Joe-

> 	- can you _ever_ get away with not counting actual packets sent?

Ah.

To flip this around: What in the draft concerns you?  What makes you
think that we did not propose a scheme that works without counting
packets?

(Sorry... I might work through all the possibilities, but I am way busy
with a deadline today.  So, I am trying to cut to the chase of what
you're getting at here.  I.e., lets focus on the draft and not start the
discussion from scratch.)

Thanks,
allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Feb 2004 08:45:36 -0800

> think that we did not propose a scheme that works without counting

Basically, it's exactly the concern that Nagle would affect it at all 
;-) I'll dig through and see if there are specifics...

---

From: Mark Allman <[email-masked]>
Date: Sun, 22 Feb 2004 17:32:15 -0500

(typing too fast)

> I guess my inclination is to punt and say you can't use ER when Nagle
> is enabled.  If a connection has enough data in flight to make the

By this I meant: I guess my inclination is to punt and say you can't use
ER when Nagle is **disabled**.

allman

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 25 Feb 2004 12:31:53 +0100

>ER when Nagle is **disabled**.

I think that would be a good way forward.

///Reiner