[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e7f8a685-9635-4aa9-bd67-1044e0720b29@email.android.com>
Date: Wed, 25 Jul 2012 03:16:44 -0400
From: Vlad Yasevich <vyasevich@...il.com>
To: Xufeng Zhang <xufengzhang.main@...il.com>
CC: xufeng zhang <xufeng.zhang@...driver.com>, sri@...ibm.com,
davem@...emloft.net, linux-sctp@...r.kernel.org,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sctp: Make "Invalid Stream Identifier" ERROR follows SACK when bundling
Xufeng Zhang <xufengzhang.main@...il.com> wrote:
>On 7/24/12, Vlad Yasevich <vyasevich@...il.com> wrote:
>>>>> And I should clarify the above judgment code.
>>>>> AFAIK, there should be two cases for the bundling when invalid
>>>stream
>>>>> identifier error happens:
>>>>> 1). COOKIE_ACK ERROR SACK
>>>>> 2). ERROR SACK
>>>>> So I need to deal with the two cases differently.
>>>>>
>>>>>
>>>> Sorry but I just don't buy that the above are the only 2 cases.
>What
>>>if there are addip chunks as well? What if there are some other
>>>extensions also. This code has to be generic enough to handle any
>>>condition.
>>>>
>>>Aha, you are right, this may happens.
>>>So I think the general solution is to fix this problem in the enqueue
>>>side.
>>>What do you think? any better suggestion!
>>>
>>
>> Don't have code in front of me but what if we carry the error
>condition to
>> where we queue the Sack and add the error side effect then?
>Yes, this is the most direct way to fix this problem.
>But I don't think it's the best way since we will take care of a lot
>of things and
>it also involves in lots of changes to side effect processing.
>I prefer to Neil Horman's way for the solution since only COOKIE_ACK
>chunk is
>allowed to place ahead of SACK chunk when bundling into one packet.
>What do you think?
>
>
Actually not true. AUTH can be before SACK. So can any addip chunks that aid in locating an association.
Now AUTH isn't a big issue since its autogenerated to the packet but ADDIP is since it could be queued up for retransmission.
There could be other extensions as well. It really needs to be done either through side effects or making error chunks go at the end of other control chunks. Need to audit the spec to see if that's ok.
-vlad
>
>Thanks,
>Xufeng Zhang
>>
>> -vlad
--
Sent from my Android phone with SkitMail. Please excuse my brevity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists