Subject: [Tsvwg] draft-dawkins-linkup-nevermind-00.txt

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 3 Mar 2004 16:46:40 +0900

I owe TSVWG a note back based on my presentation at IETF 58.

At IETF 58, I talked about LinkUp (details at
http://www.ietf.org/proceedings/03nov/247.htm, I'm not sure why my
slides didn't get into the proceedings, now that I'm actually looking
for them).

The idea was that we were retransmitting a packet when an interface
became active, as an implicit notification to a TCP with RTOed
connections that "now" might be a good time to retransmit, instead of
waiting for the full RTO interval before retransmission.

During discussion, Joe Touch pointed out that this packet had to be
discarded after Maximum Segment Life (MSL), or about two minutes, or
there would be a risk of "splicing" an old segment onto a new
connection.

This means that, for the remaining RTO retry period, it would not be
possible to send LinkUp anyway.

I happen to think that the chances of this happening in practice are
amazingly small, but they are not zero, and I accept the impossibility
of changing the semantics of TCP in this way.

So, the lesson seems to be that we can't use implicit notifications
for LinkUp, and we couldn't think of any other notifications that
could be sent implicitly. Since explicit notifications change packet
formats and start to raise problems with firewalls and NATs, I chose
not to pursue this, either.

So, thanks for your input and interest, but I won't be pursuing LinkUp
in TSVWG. I had chatted about this with Allison, but wanted to let
others know what happened and why.

Spencer Dawkins

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

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 03 Mar 2004 15:06:59 +0100

At 08:46 03.03.2004, Spencer Dawkins wrote:
>for LinkUp, 

This depends on how you define what an implicit notification is. FYI, we have in-progress-work to be submitted soon to TSVWG or TCPM (whatever people think is the more appropriate WG) that proposes one solution to the problem.

We call it "lazy RTO backoff" and the basic idea is as follows. A TCP sender that implements all the advanced loss recovery schemes (FR, SACK or NewReno, LT, and ER) may delay the RTO backoff until it has timed out N times in a row (using the non-backed-off RTO) or until T seconds after the first timeout whatever comes first. After that the normal (or a modified) RTO backoff will take place. Clearly, variations of this basic idea exists. 

DSACKs will be used to ignore DUPACKs resulting from multiple retransmits of the oldest outstanding segment. [Here the problem comes up again that the TCP receiver does not announce in the SYN/SYN-ACK whether it supports DSACKs :-(]

For example, with a 10/10 rule (N=10 and T=10s) this would mean that a TCP sender can retransmit the oldest outstanding segment every (non-backed-off) RTO 10 times or within the first 10s after the first timeout occured whatever comes first. Given today's RTO-MIN of 1 second this means it will retransmit <= 10 times with the non-backed-off RTO. [The latter is true at least for those TCPs that really use the RTO-MIN of 1 second.]

The motivation for "lazy RTO backoff" is that for TCP-Tahoe there was certainly a strong reason to do an exponential RTO backoff since the retransmission timer was the only trigger for congestion control, and every loss had to be recovered with a timeout. With FR and with all the advanced loss recovery schemes, timeouts should be rare events (although we have no data to prove this), so it should be OK to be a bit more relaxed about the RTO backoff ...

Any early comments?

///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: Reiner Ludwig <[email-masked]>
Date: Fri, 05 Mar 2004 11:12:27 +0100

Hi Mark,

of course I was expecting feedback from you on this, and I appreciate it :-)

I don't agree with you, but you raise good issues ...

(I cc:ed [email-masked] because I'd also like to hear what others think.)

At 16:05 03.03.2004, Mark Allman wrote:
>At first glance I don't understand why one should not halve the rate
>when congestion is detected.  I.e., if we have to halve the rate when
>sending at 100 pkts/RTT then why not when sending at 1 pkt/RTT?  What
>makes that a special case?  

Remember that after a timeout we have *more than halved* the rate already (unless cwnd was 2). So, we are going from 100 pkts/RTT directly to 1 pkt/RTT after *only* 1 RTO. I think that already is an extreme reaction.

[I.e., I would even argue that given FR+SACK+LT+ER a TCP sender may not have go back to "square one" (cwnd = 1) after the first timeout. But, it may be allowed to reduce cwnd to somewhere between 1 and cwnd/2. But, I don't want to start that discussion (now).]

So, I think cwnd = 1 after a timeout is already a hefty penalty for the TCP sender. And, maybe that's fine. But, I argue (under the assumption that FR, SACK, LT, and ER are enabled) against further penalizing the TCP sender with an exponential RTO right from the start. Sure, at some point there must be an RTO backoff.

I would say that after going from cwnd = 100 to 1, it should be OK to allow the TCP sender to retransmit every non-backed-off RTO for a while maybe even cwnd/2 (= 50) times. That would be a massive rate reduction: going from 100 pkts/RTT to 1 pkt/*RTO* (RTO >= 2 RTT). Don't you think? It's certainly far more than halving the rate.

>It seems to me if you take one timeout and
>need another that means you should be even more conservative because the
>network is not really in a happy place, no?

Agreed. The network *might* be under heavy congestion, but does that mean we have to *immediately* pull the breaks (reducing cwnd & RTO backoff) all the way? 

>I like the point about avoiding timeouts.  We should do that.  We should
>make timeouts rare events.  

Fully agree.

>And, if they are then it seems that
>optimizing them is not really a good idea.  

Why not? There are a number of occasions where a TCP sender has to fallback to a timeout, e.g., last packet of a short-lived connection. I would prefer to have a reasonably short RTO than one that might be up in the clouds. 

Plus, I would prefer an RTO for which we can trust that it also works with an RTO-MIN of 2 times the timer granularity.

>I really like the notion
>that we should be aggressive in avoiding the RTO, 

Agreed.

>but conservative after
>we hit it.  That provides balance to me.

I think that we had a good balance for TCP-Tahoe, but with FR+SACK+LT+ER, I think we lost the balance. And that hits hard.

///Reiner

---

From: Mark Allman <[email-masked]>
Date: Fri, 05 Mar 2004 08:09:04 -0500

[If the WG chairs wish to hand me a de-merit for being off topic, that
 would be fine with me.  I appologize for being so -- but, think someone
 needs to say something.]
 
Reiner-

Once upon a time there was email etiquette.

> (I cc:ed [email-masked] because I'd also like to hear what others

As far as I can tell, the only piece of the private response I sent to
you that you did not re-post publically without my permission was the
part at the very top of my post where I *explcitly* tagged the note as
private (with an "(offlist)" notation).  You asked for quick or early
thoughts (something to that effect) and I was happy to send off a few
quick thoughts to you.  But, I chopped the mailing list off the note
because I didn't want my thoughts to be construed as any sort of
hardened opinion (either now or down the road).  But, in the end, it
doesn't really matter *why* I chopped off the mailing list.  It was and
is *my* choice on how to scope *my* email -- and, that scope was
explicitly indicated in the mail.  I do not understand why you think it
is at all appropriate to publically post private words without
permission.  (If you really wanted to respond to the list you should
have asked me and/or just paraphrased "an opinion" you received
privately.)

And, it is not just you.  This practice seems to be happening more than
it used to (to me and to others that I have observed).  And, that is why
I am writing this on the tsvwg list...

    The practice of re-posting non-public comments in public forumns is
    rude and folk should take care to stop the practice.

Thank you.

allman

PS- As for the technical meat of your note... It misses the point and
    does not change my current feeling on the subject (maybe I did not
    clearly state my opinion; we'll explore it more at some other
    time).

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

---

From: Reiner Ludwig <[email-masked]>
Date: Fri, 05 Mar 2004 15:10:25 +0100

At 14:09 05.03.2004, Mark Allman wrote:
>Reiner-
>
>Once upon a time there was email etiquette. [...]

OK. I understand, I feel very sorry, and I hope you accept my apology!

I *had* thought about cc:ing tsvwg or not, but then I thought that you had raised very relevant concerns, and that likely others would have the same concerns. And if they didn't then at least these concerns were in fact key issues that would need to be debated sooner or later, anyway. So, I thought for myself "why repeat the same discussion on tsvwg later ..."

I see now that I didn't think long enough, and that I should have kept this private.

Sorry!

///Reiner

---

From: Mark Allman <[email-masked]>
Date: Fri, 05 Mar 2004 13:30:35 -0500

> OK. I understand, I feel very sorry, and I hope you accept my apology!

done

allman

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Mar 2004 00:03:24 -0800

Reiner Ludwig wrote:

> This depends on how you define what an implicit notification is. FYI,
> we have in-progress-work to be submitted soon to TSVWG or TCPM (whatever
> people think is the more appropriate WG) that proposes one solution to
> the problem.
> 
> We call it "lazy RTO backoff" ...
...
> For example, with a 10/10 rule (N=10 and T=10s) this would mean that
> a  TCP sender can retransmit the oldest outstanding segment every
> (non-backed-off) RTO 10 times or within the first 10s after the first
> timeout occured whatever comes first. Given today's RTO-MIN of 1 second
> this means it will retransmit <= 10 times with the non-backed-off RTO.
> [The latter is true at least for those TCPs that really use the RTO-MIN
> of 1 second.]

The issue with linkup was that packets need to be held possibly longer
than MSL. If the retransmissions don't violate MSL, it's fine (at least 
in that regard).

Joe