Subject: AW: [Tsvwg] SCTP Timestamps

From: Schruefer Wolfgang <[email-masked]>
Date: Fri, 18 Jul 2003 12:06:22 +0200

Stephan,
please see my comments below...
Wolfgang

> Von: Stephan Baucke 
> 
> 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 

I can not judge if this is a feature worth to sacrifice a bit, but there are 5 unused Bits in the DATA chunk header... 

> and (2) whether losing the additional benefits of timestamps 
> (RTTM 

Why do we loose RTTM? The timestamps (transmission and retransmission) are stored locally.

> and the ability to distinguish not only between original 
> transmission and retransmission, but between an arbitrary number of 
> consecutive retransmissions as well

Here I doubt that it makes sense to enhance the communication if more than one retransmission is needed for a significant number of packets. 

) 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 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
> 
> 
> 
> _______________________________________________
> tsvwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tsvwg
> 

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

---

From: [email-masked]
Date: Fri, 18 Jul 2003 07:43:44 -0400 (EDT)

> Why do we loose RTTM? The timestamps (transmission and retransmission) are

I think the whole purpose of using timestamp (even applicable for TCP)
rather than storing timestamps locally for RTTM was to avoid this added
state at the sender.

> Here I doubt that it makes sense to enhance the communication if more than
> one retransmission is needed for a significant number of packets.
>

I think I am missing something here? I think if we do intend to "enhance
communication" we do it correctly and for all possible cases we can,
rather than restrict ourselves to the case of "one retransmission". Note
that the consecutive retransmissions that Stephan was referring to can go
on different paths (destinations). I can still think (while using
retransmission bit) scenarios where an SCTP sender can break packet
conservation, do congestion window overgrowth and potentially harm the
network.

-Sourabh