Subject: Re: [Tsvwg] SCTP Timestamps (a Chunk Flag alternative)

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 17 Jul 2003 11:32:24 +0200

Dear all,

following the Timestamp discussion I asked myself whether there is a need to transmit any timestamp and if there are no cheaper solution. Here I will suggest a solution by using a Bit of the DATA and SACK Chunk Flags.

What we need in my understanding is a solution for the problem Stephan described at the beginning of the thread:

Resolving the retransmission ambiguity, i.e. enabling the sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk. This implies resolving a "path ambiguity" and allowing better and more frequent RTT measurements.

My thought is to sacrifice one (or two) bit(s) of the unused DATA and SACK Chunk Flags Bits to solve this problem.  The clue is that this bit should be echoed by the receiver in the SACK Chunk Flags. Let me just call this bit Mirror Bit or M-bit.  

A scenario may run like this:
- A sender sets the M-bit at any value when a DATA chunk is transmitted for the first time and stores the value together with the timestamp.

- The receiver mirrors the bit for the DATA chunk with TSN == Cumulative TSN Ack.

- When the sender recognises that the M-bit is not echoed correctly (for not retransmitted DATA), it knows that the peer does not support this feature. I think a feature negotiation at association setup is therefore not necessary.

- When the sender needs to retransmit the DATA for the first time it toggles the M-bit and stores the retransmission time.

- Up to now the sender can always resolve the chunk where a SACK refers to.

- When there is a need for further retransmissions I see three alternatives:
  ** The M-bit is toggled again and the sender assumes that the DATA chunk sent two RTO before was lost.
  ** The M-bit remains identical in all retransmissions (but e.g. a SACK for this DATA chunk may not be used any more for RTT calculation).
  ** We use two Chunk Flag Bits to mark the last four transmissions.

Is this a way worth to think further?

Wolfgang

_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg