Subject: Re: [Tsvwg] SCTP Timestamps

From: "Randall R. Stewart (home)" <[email-masked]>
Date: Mon, 04 Aug 2003 07:35:54 -0500

Brian:

A question or two below on your response here...

Brian F. G. Bidulock wrote:

>Sourabh,
>
>I agree that HEARTBEAT/ACK is not a good way to do this.  Although the
>opaque data in the chunk looks attractive, there are rather narrow rules
>for the handling of HB/ACK that have a rather different purpose.  SCTP
>relies on the HB mechanism for recovery of unavailable destinations in
>the multihomed environment and is also important for detection of lost
>ABORTs.  There are some items concerning HB that was discovered in interop
>testing that showed that rather special rules were required to accomodate
>implementations that could not (or did not) control source address vs. those
>that did.
>
>I think that by overloading HB/ACK for the purpose of doing more frequent
>RTT measurements would break the original purpose of HB/ACK: 
>
I am unclear on these three:

>testing the
>availability of desintations, 
>

>keeping RTO current on idle destinations, 
>

>and
>detecting lost ABORT chunks.
>  
>

If you (as proposed by some) include a HB with every packet carrying data
what about this breaks the above three items?

I would think you would still get an abort if the association was down 
... you would
with just sending data..

You would get a RTO update on whatever path you sent upon.. idle or not..

and you could still test a destination's reachability...

Now I am not yet through this thread ... and I am not convinced either 
way.. but
I just don't get how any of the above three are broken by the HB 
proposal.. not
sure who actually proposed it :>

R

>I too would prefer to see a different chunk, (TS chunk) bundled with all
>outgoing packets containing DATA and use an extension of the SACK chunk to 
>return pertinent timestamps.  (SACK is the right place to put it on the
>return anyways.)
>
>--brian
>
>On Wed, 16 Jul 2003, Sourabh Ladha wrote:
>
>  
>
>>>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)
>>
>>I still think if needed an optional timestamp chunk is the best way to go
>>if such an information is required.
>>
>>
>>-Sourabh
>>
>>
>>_______________________________________________
>>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: "Randall R. Stewart (home)" <[email-masked]>
Date: Tue, 05 Aug 2003 08:44:35 -0500

Armando L. Caro Jr. wrote:

>On Mon, 21 Jul 2003, Schruefer Wolfgang 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.
>  
>
Armando:

A question for you, not that I support the bit approach,  I don't
understand why one bit is not enough.

1) I know where the primary destionation is
2) I know at any time where I last sent the chunk and if
    the chunk was FR'd or not

Between all of these known's I don't see that more than one bit
would be required to detect the FIRST retransmission no matter
if it was sent to the primary or secondary..

R

>[1] http://www.cis.udel.edu/~acaro/papers/2003.icon.acaro.pdf
>
>~armando
>
>0--                                                  --0
>| Armando L. Caro Jr.      |  Protocol Engineering Lab |
>| www.cis.udel.edu/~acaro  |    University of Delaware |
>0--                                                  --0
>
>