Subject: Re: Draft on Advice for Internet Subnetwork Designers

From: Dr G Fairhurst <[email-masked]>
Date: Wed, 01 Mar 2000 13:30:30 +0100

More clarification...

Joe Touch wrote:

> > From [email-masked]  Mon Feb 28 08:05:06 2000
> > Date: Mon, 28 Feb 2000 15:06:57 +0100
> > From: Dr G Fairhurst <[email-masked]>
> > CC: "[email-masked]'" <[email-masked]>,
> >         "Phil Karn (E-mail)" <[email-masked]>
> > Subject: Re: Draft on Advice for Internet Subnetwork Designers
> >
> > Here are some comments on Link Level Issues:
> >
> > "Falk, Aaron" wrote:
> >
> > > Folks--
> > >
> > > A very important piece of work for PILC is the LINK draft that Phil Karn is
> > > editing.
> > > http://www.ietf.org/internet-drafts/draft-ietf-pilc-link-design-01.txt
> >
> > PAGE 4: MTU Size
> >
> > It may be useful to note that using IPSEC in tunnel mode can increase
> > the size of a packet as it travels across the network.  This can result
> > in a smaller MTU.
>
> Doesn't IPSEC in any mode do this? (tunnel or transport?)
>
> (provided it's added after the source - and, in the case
> of overlay networks, [paradoxically] transport may be
> more useful)

Sure, you are correct. But, I seem to remember the draft mentioning 1500B MTU.
Now, since this is a link designer's draft, what we are presumably interested in
is frame payload data size... So, if normal IP is used that is maximum 1500B.
If IPSEC is used end-to-end that is still 1500B of frame payload, even though
MTU is reduced. But with tunnel mode along part of the path, the rest of the
path outside the tunnel now sees a reduced MTU - or the tunneled path needs
to support a larger frame size.  Just saying 1500B is not a universal MTU anymore.

(P.S. GRE encapsulation, etc also have this effect).

>
> > The IPv4 packet header contains a header checksum that verifies the integrity
> > of the header. This checksum was originally design to protect from router
> > software errors, however this function is no longer necessary.
>
> Not so much necessary, as not worth the cost.
>

Better wording.

>
> > IPv6 does
> > not therefore implement a network level integrity checksum. The role of the
> > IP checksum has therefore been subsumed into the TCP and UDP
> > checksums.
>
> More into IPSEC than into TCP and UDP, no?
>

IPSEC is one way, it is not (I think) mandatory, so TCP/UDP may still get
bad packets which they have to reject....

> Joe

---

From: Dr G Fairhurst <[email-masked]>
Date: Wed, 01 Mar 2000 14:12:53 +0100

I'm following up the thread on ARQ, sorry for the delay in getting back:

Lloyd Wood wrote:

> On Mon, 28 Feb 2000, Dr G Fairhurst wrote:
>
> > "Falk, Aaron" wrote:
> >
> > > Folks--
> > >

> > (2)  Link layer protocols should provide adequate protection from
> > transmission errors.
>
> It's a tradeoff dependent on the characteristics and use of the link,
> since the end-to-end checksum catches a number of errors. If the
> reader thinks 'adequate protection' means 100% reliability means ARQ,
> you've got problems.

Adequate protection form errors, in my thinking,  means that PDUs delivered
end-to-end should not contain minimal errors.  The UDP/TCP validation
using the checksum is designed to detect computer manipulation errors
(e.g. DMA under-runs, pointer corruption, etc), not to detect random
(or burst) channel errors.  A more powerful CRC is required in this case.
This is a different issue to non-delivery. Point 3 below.

> How about:
>
>  Link layer protocols should provide adequate protection from
>  transmission errors. This is necessary since:
>  1.  there is as yet no internetwork framework for detecting or
>      handling link transmission errors effectively
>  2.  it is desirable from a performance viewpoint to avoid triggering
>      congestion control algorithms needlessly as result of errored
>      link-layer frames being discarded.
>  3.  the TCP and UDP checksums are neither strong nor foolproof.
>
> >  Whereas in previous cases, small CRCs or no CRC
> > (in the case of SLIP) have been tolerated.  A CRC-32 is desirable for
> > each packet (as in Ethernet).

>
> ...or as in ATM AAL5. The best choice of CRC might be dependent on
> advertised MTU and link characteristics; probably need a note on
> transparent fragmentation here. I can't think of any references as to
> why CRC-32 is considered adequate/sufficient offhand, but some would
> be nice.

In fact we have two ways (which may be used together).  The first is add a CRC per

segment (frame) as X.25 did. The second is add a CRC per PDU as ATM did.

The reference to CRC evaluation for ATM is

"Stone, Jonathon, Greenwood, Michael, and Partridge, Craig, Performance of CRC's
over Real Data. IEEE/ACM Transactions on Networking, 1998. 6(5): p. 529-543"

A possible reference for the thought behind per-PDU CRC rather than per segment
CRC is in:

"Wang, Zheng and Crowcroft, Jon, SEAL Detects Cell Misordering. IEEE Network,
1992. 6(4): p. 8-9"

On points 1,2, Reliable or Partial Reliable delivery implies the use of ARQ,
bit level (physical) FEC, Packet level FEC, or some hybrid of these.

>
> > I think it may be wise to note that there are two approaches to TCP
> > friendly link ARQ.  One has been put forward by Balakrishnan:
> >
> > "H. Balakrishnan, V.N. Padmanabhan, S Seshan, and R H Katz, A
> > Comparison of Mechanisms for Improving TCP Performance over
> > Wireless Links. IEEE Trans Net, 1997. 5(6): p. 756-759."
> >
> > In this case, TCP headers are read and the information used to tune
> > the link protocol.
>
> this breaks layering. Ugh. And it's a fat lot of use with e.g. IPSec.
> Not my first or recommended choice.

I'm not sure I like it, but we should be aware there are many ways of doing it,
ranging
from "looking" at headers, which is the most benign. To delaying packets,
modifying
headers and inserting extra packets, which are more pro-active.  People do this
kind
of thing, and given the right technique for the correctly identified problem may
get
big benefits.  There are problems if TCP changes, IPSEC is used (could we need a
proxy?), ECN is deployed, etc, etc.

I agree there is a warning attached here. I don't like going down this path either
:-)

> > The other approach is to bound link behaviour to match TCP
> > "requirements" i.e. A receiver may calculate the variation
> > of the recovery delay and then give up, if the variation
> > which will be introduced is more than that can be tolerated
> > by the TCP transport layer.
>
> and this assumes that the link in question is the only link in the
> path doing such calculations. ugh again.
>

To get best performance this is correct. The penalty for doing too much
retransmission is poorer link performance.  There are far fewer impacts
on TCP end-to-end behaviour.

>
> Really, you should imo be saying that if the variation is any more
> than an order of magnitude less than the limit of transparency to TCP,
> give up on the resend requests. If it's likely to be regularly more
> than an order of magnitude less than the transparency limit, be very
> skeptical of ARQ.

What do you mean by "limit of transparency"?

>
> (500ms RTO gives 50ms per-link limit, which is probably a bit on the
>  high side, given that the draft talks about 10-20ms delay already.
>  But two orders of magnitude would be 5ms. I have to stop myself
>  thinking in binary magnitudes too...)
>
> cheers,
>
> L.
>
> <[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

Best wishes,

Gorry Fairhurst.