Subject: Re: Kicking TCP

From: Vernon Schryver <[email-masked]>
Date: Wed, 8 Mar 2000 05:40:10 -0700 (MST)

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

> >Isn't this repeating of TCP segments a very limited form of ARQ? 
> >Are you sure it wouldn't be better to admit as much and then ask if
> >partial ARQ wouldn't be just as simple and more generally effective?
>
> It's not quite the same as partial ARQ.

ok, call it "sort of an imitation of a start of ARQ".

>                                         I'm assuming that the node
> with an interface on the downed link would have an out-of-band
> indication from the link level driver whether the link is up or down.
> And when it's down, it wouldn't even try to pass a queued packet to
> the link driver. It would just hold onto the most recent queued packet
> on each flow (e.g., TCP connection), overwriting it with any
> subsequent retransmission and wait for the link to come back up. When
> it does, it would forward the packet normally. Whether the packet is
> just a TCP ack or it also contains data, it should stimulate the
> sending TCP into resuming normal operation.

How does that differ from what a reasonable demand dialing PPP
implementation does the link goes down unexpected, whether because the
peer took it down or the modems (or ISDN line etc.) hiccuped?  A reasonable
PPP implementation queues the most recent N (for some reasonable N>0, but
N>typical window/negotiated MTU is good) and sends them when it can (the
link comes up or back up).  A PPP implementation that does not do this
queuing is a pain to use (or so I think), because it loses the traffic
that caused it to demand dial.  Unfortunately, many demand dialing PPP
implementations are unreasonable by this criterion.

Besides, why would there be any worry about memory space or queuing
mechanisms?  A slow-speed link router would need reasonable queuing memory
and mechanisms to handle at least one TCP window's worth of TCP/IP packets.
Even Microsoft and Sun think a TCP window should be at least 4 or 16K.

Vernon Schryver    [email-masked]

---

From: Phil Karn <[email-masked]>
Date: Thu, 9 Mar 2000 15:07:40 -0800

>implementations are unreasonable by this criterion.

My suggestion really doesn't differ, so perhaps all I need to do is
to insert language into the LINK draft that says essentially this.

Phil

---

From: Markku Kojo <[email-masked]>
Date: Fri, 10 Mar 2000 15:48:27 +0200 (EET)

> to insert language into the LINK draft that says essentially this.

Agreed. But just in case someone may interpret the statement
above differently: PPP is not used on all links/subnetworks which
have this problem; there are/will be number of (wireless) links
having the link outage problem but which are not employing PPP. 
PPP is link layer to me. And, if the actual link is of "serial type"
on which PPP is needed, then this is obviously best implemented in
PPP, otherwise this should be addressed in the link design.

Maybe this was already clear to everyone ...

/Markku