Re: Comments to "Advice for Internet Subnetwork Designers"

[Dr G Fairhurst <[e-mail]>]

See also:

draft-ietf-pilc-link-arq-issues-00.txt

Phil Karn wrote:

> Going back to some mail of yours from early August, I've been giving
> your comments a lot of thought, and I have to admit I'm moving closer
> to your point of view on some things.
>
> >>What you really want to avoid are the nasty interactions between TCP
> >>and link/physical layer retransmissions that can occur in certain link
> >>operating regions.
>
> >People often talk about those interactions as if there where so many of
> >those. What are those interactions you are talking about?
>
> >I only know of two such interactions:
> >(1) spurious timeouts that lead to a go-back-N retransmisison mode in TCP, and
>
> A compliant TCP never does go-back-N; it only retransmits the oldest
> unacked segment.  But even this could be a spurious retransmission if the earlier
> delay was caused by a link layer retransmission.
>
> >(2) out-of-order delivery at the link layer that falsely triggers fast
> >retransmit / fast recovery.
>
> I think this is not as significant a problem in practice, since most
> link layers already enforce packet ordering.

>
> >Given that PILC recommends that link layers should avoid out-of-order
> >delivery (also for the sake of not causing trouble for TCP/IP header
> >compression) this leaves spurious timeouts as the cardinal problem.
>
> But now I'm no longer sure that ordered delivery at the link level is
> even a good thing.

>
> The basic problem is that ordered delivery can only be done by
> intentionally delaying any packets that would otherwise be delivered
> out of order. This is harmless or even beneficial if the delayed
> packets belong to the same TCP connection.  But if they don't, then
> you merely impair the performance of the other connection(s) with no
> compensating benefit.

I thought PILC recommended PER-FLOW ordering. This may in many
protocols be implemented as PER-LINK or per-host-pair-of-IP-addresses,
but these are design decisions taken during the link implementation.

There are cases for out-of-order delivery between flows.
Low persistency may also reduce the head-of-line link reciever blocking
which you mention.


> (True, the link *could* peek at the TCP and IP
> headers and only enforce in-order delivery of packets belonging to the
> same TCP connection, but that would be an egregious layer violation --
> i.e., it wouldn't work with IPSEC).
>
> I believe this is much the same reasoning that originally led to the
> Internet architects to say that IP need not deliver packets in
> sequence, that reordering is a transport layer responsibility.
>
> Transport protocols can compensate for many subnetwork and Internet
> ills, including packet loss, duplication and reordering. But high
> delay is one subnetwork ill that a transport protocol can *never*
> overcome.  That's why I think any low-level mechanism that
> deliberately introduces delay should be viewed with great skepticism.
>
> This also leads to the conclusion that if packet reordering spuriously
> triggers TCP's dup ack mechanism, then this is really TCP's fault and
> it should be fixed inside TCP. (I didn't say this would be easy, though.)

That is re-ordering within a flow - I think you mean.

>
> This leaves one remaining argument for ordered delivery on links: VJ
> header compression. So we could simply say that in-order delivery is
> important only if you plan to implement VJ header compression.

V-J isn't recommended with lossey links....

There are more arguments for low link delay in:
draft-ietf-pilc-link-arq-issues-00.txt

>
> Anyway, back to retransmission interactions.
>
> >>But whenever the link layer retransmits, the RTT spikes
> >>and there's a spurious TCP retransmission.
>
> >This is a simply not true. You have to let things go really bad to force a
> >spurious timeout in TCP. Depending on your path characteristics especially
>
> You say it's rare, but it is something I've seen quite often in TCP
> traces. I think this difference is simply due to our having operated
> over different environments.  Our air links tend to have relatively
> high latencies even without link level retransmissions, and more
> significantly this latency tends to dominate that of the total
> Internet path.  So we probably see many more cases of spurious TCP
> retransmissions being triggered by link retransmissions than you do.
>
> Also, our link protocols have historically been implemented in cell
> phones with severely limited memory resources, and this has led us to
> implement non-persistent link ARQ schemes that don't require a lot of
> buffer memory.  Of course, this problem is going away over time.
>
> But perhaps you're right that, overall, it's better to not limit the
> persistence of the link layer ARQ scheme. Fair queuing might help
> limit the effect of the spurious retransmissions on other competing
> flows, for example. Also, having a highly persistent link layer ARQ
> might be the best way to help TCP recover quickly from sustained link
> outages.

FQ helps at the input to the link-ARQ, it can't help if the link propagation
delay is high and there are frames under-going error recovery.

>
>
> Phil

Gorry

------------------------------
http://www.erg.abdn.ac.uk/users/gorry