Subject: RE: [Tsvwg] SCTP Timestamps

From: [email-masked]
Date: Wed, 16 Jul 2003 21:58:22 +0300

Sourabh,

> -----Original Message-----
> From: ext Sourabh Ladha [mailto:[email-masked]]
> Sent: Wednesday, 16 July, 2003 21:44
> 
> > Yes, you are right. The HB-ACK becomes like another SACK. I 
> like these
> > ideas. Since the information contained in the HB is actually sender
> > implementation specific, each implementation can embed what 
> ever info they
> > find most useful. It's up to that implementation to be 
> effecient with
> > overhead tradeoffs.
> 
> I do not agree at all if this is a "clean" way to proceed if 
> a timestamp
> information per packet is required. The cost that you incur by
> this is a whole new definition of SACK, HB-ACK and rules 
> associated with
> these. (For example you would still need SACKs along with 
> HB-ACKs if an
> out of order, duplicate chunk is recieved)

	Hmm... Why? SACK will still be a SACK, and HB-ACK will still be what it was...

	The only thing is that you know you sent the HB together with some number of TSNs. If you receive the HB-ACK it means that the peer got the datagram, and thus he also got the DATA chunks...

	Of course you won't do anything you normally do when receiving the SACK before you actually do that...

	As I have said in a mail I have just sent, the problem will arise when the peer doesn't bundle the SACK and HB-ACK and the SACK arrives and the HB-ACK does not... But at the same point, not bundling the SACK and the HB-ACK chunks in the same datagram might even be a plus sometimes: if the problem wasn't a lost DATA but a lost SACK, the HB-ACK might "survive" and still reach the data sender...

	Probably only including the HB when retransmitting (also, in this situation I think you don't need to include a SACK normally and thus you can use its 16 bytes) and hoping the peer not sending the SACK and HB-ACK in different datagrams and that only the HB-ACK is lost, would be enough... However, if you are retransmitting, that might mean that it is more likely that packets get lost in the way (even in the return path)...

> I still think if needed an optional timestamp chunk is the 
> best way to go
> if such an information is required.

	That might be optimal, but think that being compatible with current SCTP implementations is a big plus... Maybe you even want to have both solutions to the problem... :-/

	BR Iván Arias Rodríguez

> -Sourabh

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

---

From: [email-masked]
Date: Wed, 16 Jul 2003 22:29:11 +0300

> From: ext Armando L. Caro Jr. [mailto:[email-masked]]
> Sent: Wednesday, 16 July, 2003 22:22
> 
> On Wed, 16 Jul 2003 [email-masked] wrote:
> 
> > 	Do you think it would be enough just including the HB when
> > retransmitting?
> 
> Since there is no guarantee that the HB-ACK will be bundled 
> with a SACK,
> it may get ambiguious for the sender. When a SACK arrives without a
> HB-ACK, the sender doesn't know if the SACK is (1) for the original
> transmission, (2) for a retransmission but the HB-ACK is on 
> the way, or
> (3) for a retransmission but the HB-ACK was lost.

	Yes... The point would be that when being in (2) you should wait for a while before you consider that you are either in (3) or (1).

	Since you must bundle the control chunk (i.e., HB) before the DATA ones, (2) might not be that common because the HB-ACK should be sent before the SACK (or maybe some implementation will not)... :-/

	BR Iván Arias Rodríguez

> ~armando
> 
> 0--                                                  --0
> | Armando L. Caro Jr.      |  Protocol Engineering Lab |
> | www.cis.udel.edu/~acaro  |    University of Delaware |
> 0--                                                  --0
> 
>

---

From: Schruefer Wolfgang <[email-masked]>
Date: Fri, 18 Jul 2003 11:35:54 +0200

Brian,

yes, it is normal that M-bit indications a lost, but why do you care about spurious retransmissions older than Cumulative Ack Point?
In my implementation I would not care because RTT measurement is done only for the DATA chunk at the Cumulative Ack Point.

I think it is better than dup TSN reports, because these arrive delayed.

Wolfgang  

> Von: Brian F. G. Bidulock [mailto:[email-masked]]
> Gesendet: Freitag, 18. Juli 2003 10:55
> 
> 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 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
> > 
> 
> -- 
> 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: Schruefer Wolfgang <[email-masked]>
Date: Tue, 22 Jul 2003 14:48:14 +0200

Armando,

> On Mon, 21 Jul 2003, Armando L. Caro Jr. wrote:
> 
> > > If you are not following this argument, _please_ read at
> > > least section 3
> > > of our paper. It's a short read. The full paper is only 5 pages.
> > > http://www.cis.udel.edu/~acaro/papers/2003.milcom.acaro.pdf
> >
> >
> > I studied your paper with high interest, but my conclusion is that a
> > mirrored Retransmission Flag would be a perfect solution for the
> > scenario you describe in the paper.
> >
> > With the mirrored Retransmission Flag you _can_ recalculate 
> RTO on the
> > second path. You just can not do it for the third or further paths.
> > And here I think that the third path (resp. the a RTO 
> calculation for
> > the third transmission) may not be so important to improve.
> 
> Well, your one bit solution only works if the sender follows the
> recommended mechanism for retransmissions. There hasn't been 
> a consensus
> that retransmitting on an alternate path is always the best policy. In
> fact, I would argue that it isn't. I believe that for better 
> performance
> without affecting failover performance, fast retransmits 
> should go to the
> same destination and timeout retransmits should go to an alternate
> destination [1].  With such a retransmission policy, one bit would
> not be enough. Sure we could use 2 bits, but timestamps just seems
> cleaner.
> 
> [1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf

I disagree that the one bit solution works dependent on the mechanism used for retransmission.
The sender is free how to set the Bit. If you like to perform a fast retransmit on the primary path and you want accurate RTT calculation for the alternate path, just set the Bit for the transmission on the alternate path. And the Bit would again solve your problem.

Please see the Mirrored Chunk Flag solution as a cheap tool for any sender to enhance the transmission for its special purpose.

A timestamp solution seems over-engineered to me and I suspect it is used by TCP just because no space for a Header Flag was available (????).

E.g. I can not imagine that a 12 Byte timestamp chunk would be favoured for the usage in Telephone Signaling Systems, when the average packet length is probably only 50 Bytes.

Wolfgang

---

From: Schruefer Wolfgang <[email-masked]>
Date: Thu, 17 Jul 2003 13:06:12 +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