Subject: Network Duplication

From: Chan Kwang Mien <[email-masked]>
Date: Fri, 04 Jan 2002 14:44:30 +0800

hi,

I am looking into solving problems caused by spurious retransmission. 
according to the internet draft on
Eifel algorithm and DSACK (RFC 2883), it was mentioned that spurious fast 
retransmit can be caused by
network duplication.

Can anyone tell me how does network duplication occur in the internet and 
how frequent does network duplication
occur ?
Does network duplication of packets occur during handoff from one wireless 
cell to another, or some dysfunctional
routers duplicating the packets,etc.

Thank you.

cheers,
Kwang Mien

---

From: der Mouse <[email-masked]>
Date: Fri, 4 Jan 2002 02:16:35 -0500 (EST)

> Can anyone tell me how does network duplication occur in the internet

I've seen it occur under circumstances that make me suspect flaky MAC
address filtering in Ethernet hardware:

Machine A, MAC address MA, sends through gateway G, MAC address MG.

Machine C, MAC address MC, is on the same (non-switched) segment S as A
and G.

Two copies of the packet come out the far side of G.  Sniffing on S
sees two copes, each addressed to MG, one with MA as source and one
with MC as source.

The most plausible explanation that occurs to me is that C's hardware
incorrectly received the packet and C's kernel then "forwarded" it to G
(which was the correct next hop for that packet, for A and C both).
This could also occur if the hardware is running promiscuous but the
kernel isn't filtering out packets that aren't for it before handing
stuff to the protocol stack (either because its kernel isn't smart
enough or because it thinks the harware isn't promiscuous and hence
that the check is unnecessary).

Unfortunately I didn't think to check at the time whether the TTL in
the copy from MC was one lower than the TTL in the copy from MA.

I have also seen very long delay times, on the order of several
seconds; a long-delayed packet can "duplicate" its retransmission.  But
from the rest of your question, I suspect you aren't particularly
interested in this case.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: "Andrei Gurtov" <[email-masked]>
Date: Sun, 6 Jan 2002 15:21:43 +0200

Noritoshi-

    I agree with you.  According to a comment on Steven's page this fix is
used by all modern TCPs. Do you happen to have some experimental data that
show RFC1323-like and fixed behavior?

    In addtion to inflating RTO value, echoing old timestamps can cause
problems to the Eifel algorithm. According to Pasi Sarolahti, Linux follows
RFC1323  that lets Eifel to incorrectly conclude a spurious timeout in a
scenario with lost packets and ACKs.

Andrei

----- Original Message -----
From: "Noritoshi Demizu" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Thursday, December 27, 2001 10:58 AM
Subject: Re: Doubt regarding the MANAGING THE RTO TIMER

> > When using Timestamps, even in the face of packet loss,
>  > you can guarantee to get at least one valid timing per RTT.
>  > Or, more correctly, with Timestamps, anytime you get an
>  > ack for new data, you can reliably use it's timestamp
>  > to get a new RTT measurement.
>
> I think RFC1323 needs to be updated as described in [1] and [2] bellow.
>
> If one implemented timestamps option just as described in RFC1323, and
> when a data packet was retransmitted because the ACK packet was lost,
> the measured RTT could be larger than the real value.  To fix this
> problem, at least the condition of the rule (2) of section 3.4 in
> RFC1323 needs to be updated.
>
>   The condition of the rule (2) of Section 3.4 in RFC1323 is:
>         SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN
>
>   The condition of [1] and [2] is:
>         SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent
>
>   The condition of FreeBSD 4.4R is: SEG.SEQ <= Last.ACK.sent
>   The condition of NetBSD 1.5.2 is the same as RFC1323.
>   The condition of OpenBSD 3.0 is the same as [1] and [2].
>   (Sorry, I do not know of the Linux implementation.)
>
> [1] R. Braden, "TCP Extensions for High Performance: An Update", Jun 1993
>     http://www.kohala.com/start/tcplw-extensions.txt
> [2] V. Jacobson, R. Braden and D. Borman, "TCP Extensions for High
>     Performance", Feb 1997
>
http://www.watersprings.org/pub/id/draft-ietf-tcplw-high-performance-00.txt
>
> I hope RFC1323 will be updated.
>
> Noritoshi Demizu
>

---

From: Noritoshi Demizu <[email-masked]>
Date: Mon, 07 Jan 2002 17:46:13 +0900

Andrei,

 > show RFC1323-like and fixed behavior?

Yes.  I have implemented the features listed in "WAP Wireless Profiled
TCP (WAP-225-TCP)" and <draft-ietf-pilc-2.5g3g-05.txt>, including TCP
timestamps options, for the TCP/IP stack of ACCESS (www.access.co.jp)
which I am working for.  During the test period, I found the problem.

I tried to reproduce the phenomena today.  Here are two traces at the
receivers side.  Both the sender and the receiver are ACCESS's stacks.
The RTT is approximately 50ms.  The timestamp counts up every 500ms.

-------------------------------------------------------------------------
When both the sender and the receiver follow RFC1323:
i.e. SEG.SEQ <= Last.ACK.sent < SEG.SEQ + SEG.LEN

  Scenario:
  - Packet (1) triggers Fast Retransmit(2) at the sender.
  - The receiver sent an ACK(3) for data(2), but the ACK was dropped.
  - The sender retransmitted data twice, but they both were dropped.
  - The receiver sent an ACK(5) for data(4), and the ACK arrived at the sender.
  - The sender sent new data(6).  The recever sent an ACK(7).

  See the timestamp echo value of ACK(5).  Because this is the first ACK of
  66609 for the sender, the sender calculates RTT with this very old value.
  The calculated RTT might be about 10sec (= (36 - 15) * 500ms).  Too big...

(1) 16:04:15.927928 receiver.9 > sender.1128: . ack 59369 win 32768 <nop,nop,timestamp 28 15,nop,nop,sack sack 1 {60817:66609} > (DF)
(2) 16:04:15.979703 sender.1128 > receiver.9: . 59369:60817(1448) ack 1 win 32768 <nop,nop,timestamp 15 17> (DF)
(3) 16:04:15.979947 receiver.9 > sender.1128: . ack 66609 win 32768 <nop,nop,timestamp 28 15> (DF)
(4) 16:04:27.228887 sender.1128 > receiver.9: . 59369:60817(1448) ack 1 win 32768 <nop,nop,timestamp 35 17> (DF)
(5) 16:04:27.229154 receiver.9 > sender.1128: . ack 66609 win 32768 <nop,nop,timestamp 49 15> (DF)
(6)16:04:27.280868 sender.1128 > receiver.9: . 66609:68057(1448) ack 1 win 32768 <nop,nop,timestamp 36 17> (DF) [tos 0x2,ECT]
(7) 16:04:27.294183 receiver.9 > sender.1128: . ack 68057 win 32768 <nop,nop,timestamp 49 36> (DF)

-------------------------------------------------------------------------
When both the sender and the receiver follow fixed RFC1323:
i.e. SEG.TSval >= TSrecent && SEG.SEQ <= Last.ACK.sent

  Scenario:
  - The sender sent data(1)&(2).  The receiver sent an ACK(3), but dropped.
  - The sender sent data(4)&(5).  The receiver sent an ACK(6), but dropped.
  - The sender retransmitted data(7), the same data as data(1).
  - The receiver sent an ACK(8) with correct timestamp echo value.
  - The sender sent new data(9).  The recever sent an ACK(10).

  See the timestamp echo value of ACK(8).  Because this is the first ACK of
  215753 for the sender, the sender calculates RTT with this value.
  The calculated RTT might be about 500ms (= (26 - 25) * 500ms).  Not bad.

(1) 15:54:26.170476 sender.1558 > receiver.9: . 209961:211409(1448) ack 1 win 32768 <nop,nop,timestamp 23 38> (DF) [tos 0x2,ECT]
(2) 15:54:26.201471 sender.1558 > receiver.9: . 211409:212857(1448) ack 1 win 32768 <nop,nop,timestamp 23 38> (DF) [tos 0x2,ECT]
(3) 15:54:26.201615 receiver.9 > sender.1558: . ack 212857 win 32768 <nop,nop,timestamp 38 23> (DF)
(4) 15:54:26.232467 sender.1558 > receiver.9: . 212857:214305(1448) ack 1 win 32768 <nop,nop,timestamp 23 38> (DF) [tos 0x2,ECT]
(5) 15:54:26.263466 sender.1558 > receiver.9: . 214305:215753(1448) ack 1 win 32768 <nop,nop,timestamp 23 38> (DF) [tos 0x2,ECT]
(6) 15:54:26.263617 receiver.9 > sender.1558: . ack 215753 win 32768 <nop,nop,timestamp 38 23> (DF)
(7) 15:54:27.359400 sender.1558 > receiver.9: . 209961:211409(1448) ack 1 win 32768 <nop,nop,timestamp 25 38> (DF)
(8) 15:54:27.359632 receiver.9 > sender.1558: . ack 215753 win 32768 <nop,nop,timestamp 40 25> (DF)
(9) 15:54:27.411389 sender.1558 > receiver.9: . 215753:217201(1448) ack 1 win 32768 <nop,nop,timestamp 26 40> (DF) [tos 0x2,ECT]
(10) 15:54:27.435141 receiver.9 > sender.1558: . ack 217201 win 32768 <nop,nop,timestamp 41 26> (DF)

-------------------------------------------------------------------------

Regards,
Noritoshi Demizu