Re: One DataAckSNACK for two "A"s

"Eddy Quicksall" <[email protected]>
Newsgroups gmane.ietf.ips
Message-ID <[email protected]>
In my example there is no problem with the first sequence. The example is created by the initiator being "smart" if it is a little slow and receives both sequences very close together hence deciding that it only needs to send the DataAckSNACK for the 2nd in order to cover both. The target should be able to figure out that both sequences have been received by the initiator by checking BegRun.

The BegRun for a DataAckSNACK is the next expected DataSN so it would be set for the 2nd sequence which covers both sequences.

Eddy
  ----- Original Message ----- 
  From: William Studenmund 
  To: Eddy Quicksall 
  Cc: [email protected] 
  Sent: Monday, March 27, 2006 11:01 PM
  Subject: Re: [Ips] One DataAckSNACK for two "A"s


  On Mar 27, 2006, at 6:14 PM, Eddy Quicksall wrote:


    Suppose the target sends two sequences with the A bit set (both for the same task and both are within the length constraints that apply to the use of the A bit). Also assume DataSequenceInOrder is Yes.

    Can the initiator send just one DataAckSNACK after the 2nd sequence with the appropriate BegRun for the 2nd sequence?


  What is the initiator trying to do? From reading the RFC, the initiator can in fact do this. However this would imply that there was an issue with the first sequence and that it is being re-requested.


  I think it would also be reasonable to have one DataAckSNACK that covered both runs, but in that case you'd start with the BegRun from the 1st sequence.


  Take care,


  Bill


------------------------------------------------------------------------------


  _______________________________________________
  Ips mailing list
  [email protected]
  https://www1.ietf.org/mailman/listinfo/ips

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.