Subject: Re: [Tsvwg] SCTP Timestamps

From: Schruefer Wolfgang <[email-masked]>
Date: Fri, 18 Jul 2003 10:26:18 +0200

Dear all,

I will suggest an alternative solution, how to enable a sender to determine whether an ACK refers to the original transmission or a retransmission of a chunk.

My thought is to sacrifice one of the unused bits in the Chunk Flags field of the DATA and SACK chunks to solve the problem. The clue is that the value of this bit from the DATA chunk should be echoed by the receiver in the SACK chunk. A feature negotiation at association setup is not necessary, because the sender recognises early if the feature is supported by the peer or not.

A scenario may run like this (let me just call this new bit Mirror Bit or M-bit): 

- 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.

- In the SACK the receiver mirrors the M-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. 

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

- For up to one retransmission the sender can 100% 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 earlier 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 while to think about?

Wolfgang

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. 
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

Viele Gruesse
Wolfgang Schruefer

Siemens ICN CP D NP A8
TEL: +49 89 722-61646 

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Fri, 18 Jul 2003 02:55:24 -0600

Wolfgang,

What about the packet that contains:

  RTx (2) DATA RTx (2) DATA RTx (1) DATA New DATA New DATA

from two separate retransmissions.

What about when the spurious retransmissions are before the
Cummulative Ack point (due to loss of SACKs)?  Won't these
M-bit indications be lost?

Doesn't sound better than existing dup TSN reports in SACKs.

--brian

On Fri, 18 Jul 2003, Schruefer Wolfgang wrote:

> Dear all,
> 
> I will suggest an alternative solution, how to enable a sender to determine
> whether an ACK refers to the original transmission or a retransmission of a
> chunk.
> 
> My thought is to sacrifice one of the unused bits in the Chunk Flags field
> of the DATA and SACK chunks to solve the problem. The clue is that the value
> of this bit from the DATA chunk should be echoed by the receiver in the SACK
> chunk. A feature negotiation at association setup is not necessary, because
> the sender recognises early if the feature is supported by the peer or not.
> 
> 
> - 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.
> 
> - 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. 
> 
> - When the sender needs to retransmit the DATA for the first time it toggles
> the M-bit and stores the retransmission time.
> 
> ** The M-bit is toggled again and the sender assumes that the DATA chunk
> sent two RTO earlier 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.
> 
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Stephan Baucke <[email-masked]>
Date: Fri, 18 Jul 2003 11:30:21 +0200

Wolfgang,

this is indeed another way to resolve the retransmission ambiguity (in 
fact the first proposal of the Eifel algorithm for TCP used this 
method). The questions are whether (1) there are header bits available 
for this and (2) whether losing the additional benefits of timestamps 
(RTTM and the ability to distinguish not only between original 
transmission and retransmission, but between an arbitrary number of 
consecutive retransmissions as well) is a serious concern.

Stephan.

Schruefer Wolfgang wrote:

> Dear all,
> 
> I will suggest an alternative solution, how to enable a sender to
> determine whether an ACK refers to the original transmission or a
> retransmission of a chunk.
> 
> My thought is to sacrifice one of the unused bits in the Chunk Flags
> field of the DATA and SACK chunks to solve the problem. The clue is
> that the value of this bit from the DATA chunk should be echoed by
> the receiver in the SACK chunk. A feature negotiation at association
> setup is not necessary, because the sender recognises early if the
> feature is supported by the peer or not.
> 
> 
> - 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.
> 
> - 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.
> 
> - When the sender needs to retransmit the DATA for the first time it
> toggles the M-bit and stores the retransmission time.
> 
> - 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 earlier 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.
> 
> 
> following the Timestamp discussion I asked myself whether there is a
> need to transmit any timestamp and if there are no cheaper solution.
>  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.
> 
> - 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.
> 
> - 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.
> 
> 
> Viele Gruesse Wolfgang Schruefer
> 
> Siemens ICN CP D NP A8 TEL: +49 89 722-61646
> 
> 
> _______________________________________________ tsvwg mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/tsvwg