Re: Abort chunk bundled with data chunk
Michael Tüxen <[email protected]>
| Newsgroups | gmane.ietf.sigtran |
|---|---|
| Message-ID | <[email protected]> |
On Oct 15, 2009, at 11:06 AM, Salil Agrawal wrote: > Thanks Ashwani, > > That means if we receive any DATA chunk in a packet then we first need > to check if this packet contains the ABORT or not before sending the > SACK. If packet is not containing the ABORT then only SACK will we > sent > otherwise not. I would just start processing the packet, process the DATA chunk, find the ABORT, decide the packet is illegal, discard the association, and do not send an ABORT since I received one. Best regards Michael > Also if this is going to be expected behavior then it would impact the > protocol performance as we need to traverse the whole packet before > sending any SACK. > > Thanks, > Salil > > > > -----Original Message----- > From: Ashwani Kathuria [mailto:[email protected]] > Sent: Thursday, October 15, 2009 2:30 PM > To: Salil Agrawal > Cc: [email protected] > Subject: Re: [Sigtran] Abort chunk bundled with data chunk > > No, SACK should not be sent in such case. > > On Thu, Oct 15, 2009 at 2:28 PM, Salil Agrawal > <[email protected]> > wrote: >> Hi Ashwani, >> >> The question is not that whether DATA chunk should be bundled with >> the >> ABORT or not. RFC is very clear about it that the sender should not >> do >> in that way but here the question is if we at the receiver end > receives >> the same then what should be the action at the receiver end (should >> we >> send the SACK for the DATA or not). >> >> Thanks, >> Salil >> >> -----Original Message----- >> From: Ashwani Kathuria [mailto:[email protected]] >> Sent: Thursday, October 15, 2009 2:11 PM >> To: Salil Agrawal >> Cc: [email protected] >> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >> >> Placing DATA chunk before control chunk (ABORT) makes it an Invalid > SCTP >> packet. >> >> --Ashwani Kathuria >> >> On Thu, Oct 15, 2009 at 1:46 PM, Salil Agrawal > <[email protected]> >> wrote: >>> Thanks Ashwani, >>> >>> I understand that it does not make any sense to send the SACK, and >> abort >>> chunk should be the placed before the DATA chunk. But the question >>> is >> if >>> the ABORT chunk is placed after the DATA chunk in the received >>> packet >>> then should be send the SACK for the DATA or not. >>> >>> Thanks, >>> Salil >>> >>> >>> -----Original Message----- >>> From: Ashwani Kathuria [mailto:[email protected]] >>> Sent: Thursday, October 15, 2009 12:58 PM >>> To: Salil Agrawal >>> Cc: [email protected] >>> Subject: Re: [Sigtran] Abort chunk bundled with data chunk >>> >>> Hi Salil, >>> >>> When you are bundling anything (control chunk) with DATA chunk it >>> should be placed before DATA chunks in the SCTP packets. >>> Now if you bundle the ABORT chunk with DATA chunk in a single SCTP >>> packet the ABORT chunk will be processed before DATA chunk and >>> association will be broken down. >>> So, that DATA chunk will have no significance as it's association is >>> now broken by the ABORT chunk placed before it. >>> >>> --Ashwani Kathuria >>> >>> On Thu, Oct 15, 2009 at 12:37 PM, Salil Agrawal >> <[email protected]> >>> wrote: >>>> Hi, >>>> >>>> We have a confusion while understanding the SCTP RFC4960 section >>>> 9.1 >>> it >>>> says "DATA chunks MUST NOT be bundled with ABORT" so sender must >>>> not >>>> bundle the data with abort. >>>> >>>> But the second paragraph states that "An endpoint MUST NOT respond > to >>>> any received packet that contains an ABORT chunk". Which means if > any >>>> packet is received at the receiver end where ABORT is bundled with >> the >>>> DATA it should not send any response. Does it mean that for the >>>> DATA >>>> chunk SACK should not be generated? Please clarify. >>>> >>>> Thanks, >>>> Salil Agrawal >>>> _______________________________________________ >>>> Sigtran mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/sigtran >>>> >>> >> > _______________________________________________ > Sigtran mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/sigtran >