Subject: Re: Kicking TCP

From: Vernon Schryver <[email-masked]>
Date: Thu, 9 Mar 2000 16:55:44 -0700 (MST)

> From: Phil Karn <[email-masked]>

> ...
> > 1. have the link layer tell the TCP state machines to retransmit any
> >  unacknowledged TCP bytes by forcing their retransmission timers
> >  to zero? ...

> It's more than a technical layering violation, because how would
> you do it if the TCP and the link layer are on separate machines?
> You'd need to define some communication mechanism, which was the
> intent of my ICMP SE message.

Yes, but in many cases (e.g. mobile phones) the host and the router
are pretty close to each other.  But I agree that reasonable queuing
next to the link is far better.

> ...
> Again, I agree. I will add text that encourages the subnetwork designer
> to use any internal information it may have about the state of the
> link or subnetwork to block the acceptance of IP packets if it is clear
> that those packets would be dropped, and to hold onto the most recent
> packets that it may have accepted before the link/subnet went down
> and to try to deliver them after the link/subnet comes back up.

That sound great.

Something I forget to mention in my previous note is that private
cooresondent pointed out that RED and other fancy queuing disciplines
tend to encourage dropping the most recent instead oldest packets.

Vernon Schryver    [email-masked]

---

From: Phil Karn <[email-masked]>
Date: Thu, 9 Mar 2000 22:20:55 -0800

>tend to encourage dropping the most recent instead oldest packets.

Did you mean to say that? Before RED, the usual scheme was to drop all
new packets when the queue filled up. With RED, you pick a packet at
random from the queue, so the older packets can get dropped too.

It seems to me that simply implementing RED in the IP router that
drives a link subject to outages will pretty much implement my
suggestion as long as the subnet doesn't take anything out of the IP
send queue as long as its down. During the outage, RED will continue
to manage the IP queue as new packets arrive. When the outage is over,
the survivors on the queue will be sent. Hopefully that will include
at least one packet per pending TCP connection.

Fortunately, most "flaky links" rarely carry more than one active TCP
connection at a time, so this should usually be the case.

Phil

---

From: Grenville Armitage <[email-masked]>
Date: Thu, 09 Mar 2000 22:41:27 -0800

> random from the queue, so the older packets can get dropped too.

Not exactly - RED just randomizes the drop/insert decision made
by the queue manager for a newly arrived packet. To the best
of my knowledge, there's nothing inherent in the RED scheme that
requires randomly choosing a packet currently *in* the queue for
dropping. (A minor optimization is to use the arrival of a new
packet to trigger a random decision to drop from front...)

But that's an aside - the observation that queues have enough space
to hold a windows worth of packets from the active flows (either
because the queue is big, or the number of flows is small) makes
the issue moot wrt kicking TCP.

cheers,
the-private-correspondent :)

---

From: Phil Karn <[email-masked]>
Date: Fri, 10 Mar 2000 11:22:59 -0800

>dropping. (A minor optimization is to use the arrival of a new

I thought it did, but it's been a while since I read up on it.

Phil

---

From: Vincent Magret <[email-masked]>
Date: Fri, 10 Mar 2000 14:41:55 -0600

> next to the link is far better.

What about the case where the mobile regain connectivity with another router
(of Base station)? Then aren't we loosing all the advantage of queueing?

Vincent