Bug 2883 – SND.NXT trace source is misleading

Bug 2883 - SND.NXT trace source is misleading


Summary:	SND.NXT trace source is misleading

Status:	NEW

Product:	ns-3
Classification:	Unclassified
Component:	tcp
Version:	ns-3-dev
Hardware:	All All

Importance:	P3 enhancement
Assigned To:	natale.patriciello

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2018-02-23 05:49 EST by natale.patriciello
Modified:	2018-02-23 05:50 EST (History)
CC List:	4 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description natale.patriciello 2018-02-23 05:49:54 EST

The TCP module updates proactively the value of SND.NXT. It can happen that, due to received dupack (or SACK option) the value of SND.NXT is not the value that really will be transmitted next.

For example, SND.NEXT = 4.
Then I receive a SACK option that indicates that the block 2 is lost. Then, the implementation will simply transmit 2, because NextSeg will say "ehi, the next sequence to transmit is 2". SND.NXT is updated to 2, and 2 transmitted.

So, the value of 4 is not on the wire, will be transmitted later.

I propose to set up another trace value -- maybe "TxSeq" -- that reports the real sequence number transmitted on the wire, with a documentation update on the difference between the two values.

What do you think?