Subject: Re: [Tsvwg] Rethinking Karn's algorithm

From: Phil Karn <[email-masked]>
Date: Wed, 09 Apr 2003 18:14:00 -0700

Reiner Ludwig wrote:

> I guess the times when LANs where interconnected by slow dial-up 
> connections are long gone ... and if they still exist then they 
> certainly don't pose a threat to the stability of the (public) Internet.

I disagree. While many fixed networks are indeed now connected over 
links much faster than slow dialups, there are some important wireless 
situations where conditions are very much like those of the Internet 15 
years ago.

Imagine a self-contained gateway router with 802.11 on one side and a 3G 
(or CDMA, or whatever) cell phone on the other. I envision these things 
being used to provide temporary Internet access to a group in a hotel 
conference room where the hotel doesn't already provide Internet access. 
Here you have a LAN that can potentially generate a lot of traffic being 
linked to the public Internet over a relatively slow (by LAN standards) 
link. It is still important for TCP to be conservative in such 
situations, don't you think?

Phil

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

---

From: Phil Karn <[email-masked]>
Date: Wed, 09 Apr 2003 18:33:32 -0700

Reiner Ludwig wrote:

> 1. With timestamps, we can also take valid RTTs from retransmitted 
> segments.

One major difference that *does* exist between the Internet of 15 years 
ago and the Internet of today is that TCP header timestamps are now very 
widespread. Nearly all TCPs support them: Linux enables them by default, 
while W2K (and 98, I think) implement them but you have to turn them on.

TCP header timestamps have made my algorithm essentially obsolete, as 
they eliminates the "retransmission ambiguity" problem I was trying to 
solve. You just echo back each timestamp as you get it, and you don't 
care whether the timestamp is on the first transmission of a particular 
segment or its retransmission. I knew at the time I wrote my paper with 
Craig that this was possible, but I was interested in algorithms that 
could work with the existing TCP header.

Header overhead is a non-issue here, IHMO. The savings in unnecessary 
retransmits more than pays back the investment in a larger TCP header.

Phil

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 28 Apr 2003 15:17:31 +0200

At 03:33 10.04.2003, Phil Karn wrote:
>TCP header timestamps have made my algorithm essentially obsolete, [...]
>

catching up ...

I pretty much agree since that is also what we have seen in our investigations.

A different question that was discussed before on the list is the 
exponential backoff; up to ~60 seconds. Don't you think that that is a bit 
too conservative?

///Reiner

---

From: Spencer Dawkins <[email-masked]>
Date: Mon, 28 Apr 2003 08:05:53 -0700 (PDT)

And, just so I'm not confused and confusing others...

The one notification that we had room-consensus on at the San
Francisco Trigtran BoF was "link up", which makes 

- less sense when you're talking about an RTO that's backed off
to 2-3 seconds, and 

- more sense when you're talking about an RTO that's backed off
to 60 seconds.

What I think Reiner and I are both asking, on two different
mailing lists under two different threads, is "how do we keep
fully-backed-off TCPs from waiting for 30 seconds, on average,
with a human in the loop and a working connection path, before
the TCP figures out that the connection path is working?"

So, if people think the Internet would melt down if the maximum
RTO timer was reduced to 10 seconds, that's interesting; if
people think the Internet would not melt down if it was reduced
to 15 seconds, that's also interesting ...

But I would also like to see other opinions expressed here
(Reiner and I already talk, so ...).

Spencer

---

From: Mark Allman <[email-masked]>
Date: Mon, 28 Apr 2003 11:45:00 -0400

Spencer-

Nobody answers my questions, so I am using that spirit to not answer
your's, but rather to turn it around on you... :)

> RTO timer was reduced to 10 seconds, that's interesting; if people
> think the Internet would not melt down if it was reduced to 15
> seconds, that's also interesting ...

What I am interested in knowing is where you think the line needs to
be drawn to obviate the need for link-up.  If an average wait of 30
seconds is too much what about 15 seconds?  10?  5?  2?

Now I'll sort of answer your question... I believe that the max RTO
should be "significant".  It should not be 3 seconds.  Should it be
60 seconds?  Maybe not.  Is it worth worrying about?  Well, I think
that depends on your answer to the above question.

allman

--
Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Reiner Ludwig <[email-masked]>
Date: Wed, 30 Apr 2003 10:45:19 +0200

At 22:13 28.04.2003, Phil Karn wrote:
>>exponential backoff; up to ~60 seconds. Don't you think that that is a 
>>bit too conservative?
>
>Well, I have seen some router queues that get amazingly long...

Are you saying that because we *might* have a *few* broken boxes in the 
Internet all TCPs must "suffer" and do exponential RTO backoff up to 60 
seconds?

I hate to say it, but with claims like yours I can probably kill any 
attempt to modify or add new features to an e2e protocol. To me this is 
only creating "worst-case paranoia", and that's not constructive!

The discussions around packet reordering is going in a similar direction. 
Sure, there could be backbone routers connected by multiple links for 
redundancy, and the load balancing software might not care to keep packets 
of the same flow on the same link. And voila, we have huge reordering 
problems in the Internet; and for TCP.

Now, we could have Best-Current-Practice RFCs that recommend routers: 
"don't queue more than 10 seconds worth of data", "don't throw packets of 
the same flow (or dest. IP addr.) onto different links", etc. in case they 
don't already do that, anyway (which I personally believe is mostly the 
case); then trust that this is the case in most places of the Internet, and 
design our e2e protocols towards that.
Or, we continue to believe that the Internet is a *possibly* crazy 
black-box, and design our e2e protocols with maximum conservativeness.

///Reiner

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 30 Apr 2003 18:20:29 -0500

On 4/30/03, Reiner Ludwig wrote:

>>>A different question that was discussed before on the
>>>list is the exponential backoff; up to ~60 seconds.
>>>Don't you think that that is a bit too conservative?
>>
>Are you saying that because we *might* have a *few* broken
>boxes in the Internet all TCPs must "suffer" and do
>exponential RTO backoff up to 60 seconds?
>
>I hate to say it, but with claims like yours I can
>probably kill any attempt to modify or add new features to
>an e2e protocol. To me this is only creating "worst-case
>paranoia", and that's not constructive!
>
>The discussions around packet reordering is going in a
>similar direction. Sure, there could be backbone routers
>connected by multiple links for redundancy, and the load
>balancing software might not care to keep packets of the
>same flow on the same link. And voila, we have huge
>reordering problems in the Internet; and for TCP.
>
>Now, we could have Best-Current-Practice RFCs that
>recommend routers: "don't queue more than 10 seconds worth
>of data", "don't throw packets of the same flow (or dest.
>IP addr.) onto different links", etc. in case they don't
>already do that, anyway (which I personally believe is
>mostly the case); then trust that this is the case in most
>places of the Internet, and design our e2e protocols
>towards that. Or, we continue to believe that the Internet
>is a *possibly* crazy black-box, and design our e2e
>protocols with maximum conservativeness.
>

To agree with you even more strongly, consider that for
many applications a human is part of the "backoff
algorithm".

In onther words, how long of a delay will be *tolerated*
before the human consumer initiates corrective action,
such as a new connection, on their own.

Once predictable human responses are factored in, I doubt
that a 60 second backoff will ever truly result in improved
service.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Qiaobing Xie <[email-masked]>
Date: Wed, 30 Apr 2003 18:53:40 -0500

Caitlin Bestler wrote:
...
> that a 60 second backoff will ever truly result in improved

Aren't lining up and waiting to be served part of the fun of being
human? :-)

-Qiaobing

---

From: Randall Stewart <[email-masked]>
Date: Wed, 30 Apr 2003 19:48:39 -0500

> Aren't lining up and waiting to be served part of the fun of being

Maybe..

But when you give the human another choice... (a different line
to go into) they will run to it... screwing up everything as
murphy puts it..

You can think of a different line as the little stop/reload button
on your web browser... gets a new connection and in cases of
congestion.. guess what.. it will speed things up at times...

So unless we take the "get a new connection aka switch lines" buttons
off of all applications I can't help but agree with Caitlin..

R

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 30 Apr 2003 19:30:44 -0700 (PDT)

So I'm thinking that 

- the 60 second max RTO is to save the Internet from connections
between computers that don't have humans in the loop, and 

- the stop/reload button is to save humans in the loop from the
60 second max RTO?

:-}

Spencer