Subject: Re: Correcting LINK (Advice for Internet Subnetwork Designers)

From: [email-masked] (Joe Gwinn)
Date: Thu, 1 Mar 2001 17:23:11 -0500

At 1:30 PM 1/3/1, Phil Karn wrote:
>>All other IETF protocol descriptions concerning IP packet size work in
>>octets. I see packet size, I think octets. If you're already talking
>
>Well, yes...but we have already introduced the term "BIT error rate" (ber).
>I think people can keep the distinction, and by defining PACKET_SIZE
>in bits I can tighten up all the equations by dropping the x8 factor.

Be careful.  The Ada folk tried having all lengths be in bits, and were
forever having factor-of-eight problems.  The world was just too used to
lengths being expressed in bytes (octets), and it proved too hard to change
gears.

Joe

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 2 Mar 2001 13:14:50 -0700 (MST)

> From: Joe Touch <[email-masked]>

> > ...
> > real-world respects:  a) no more IP ID, just to save 16 bits, so no more
>>ability to easily detect switching/bridging loops with a pkt analyzer (seeing
> > pkts with same ID on same LAN segment) ...

>     ... Bridges that tossed replicated IDs would make two mistakes:
>
>   - dropping packets that for which ID was undefined anyway (if frag not
> set)
> 	
>   - dropping packets intended to for FEC (see RFC791's example of TCP
> retransmits)

Yes, anyone who assumes that a duplicate TCP/IP packet is necessarily
the result of duplication such as by a switching/bridging loop should
the advice in the fourth paragraph of the section "Identification" on
page 29 of RFC 791.  However the word "forward" in FEC doesn't sound
right when applied to retransmissions.

Besides, a 16-bit ID must repeat within 64K IP packets, or 95 MBytes
with a 1500 byte MSS.  Any box that watched for duplicated IP ID's
would be too smart by half, unless it were trying to impose the rather
low speed limit of 95 MByte/ MSL or less than 1 MByte/sec.

There are the many other causes of duplicate IP ID's.

Vernon Schryver    [email-masked]