t;> In case a node does not have enough resources to handle concurrent 6P
>> Transactions from different neighbors or if the cells requested are
>> locked, it MUST reply to that second request with a 6P Response with return
>> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY
the cells requested are
> locked, it MUST reply to that second request with a 6P Response with return
> code IANA_6TOP_RC_BUSY. The node receiving IANA_6TOP_RC_BUSY may implement
> a retry as decided by the Scheduling Function
>
> >>>>>>>
>
> Does it make sens
g IANA_6TOP_RC_BUSY may implement
>>> a retry as decided by the Scheduling Function
>>>
>>>
>>>
>>> >>>>>>>
>>>
>>>
>>>
>>> Does it make sense ..
>>>
>>>
>>>
>>>
ocated, or released.
>>
>> If a node receives a transaction while another transaction is ongoing,
>> and that subsequent transaction involved the same cells, the mote MUST
>> reply to that second request with a 6P Response with return code
>> IANA_6TOP_RC_BUSY.
>>
>&g
;
> *From:* 6tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Thomas
> Watteyne
> *Sent:* 23 May 2016 18:03
> *To:* Lijo Thomas
> *Cc:* 6tisch@ietf.org; Prof. Diego Dujovne; Xavier Vilajosana
>
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
>
23 May 2016 18:03
To: Lijo Thomas
Cc: 6tisch@ietf.org; Prof. Diego Dujovne; Xavier Vilajosana
Subject: Re: [6tisch] New error type for concurrent transactions on 6top
protocol draft
All,
We have reached a consensus, in summary:
- a 6P transaction is not infinitely fast, we need to guarantee
er
> Vilajosana
> *Sent:* 19 May 2016 12:03
> *To:* Prof. Diego Dujovne
> *Cc:* Lijo Thomas; 6tisch@ietf.org
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hola Diego,
>
>
>
> according to the 6top d
boun...@ietf.org] On Behalf Of Xavier Vilajosana
Sent: 19 May 2016 12:03
To: Prof. Diego Dujovne
Cc: Lijo Thomas; 6tisch@ietf.org
Subject: Re: [6tisch] New error type for concurrent transactions on 6top
protocol draft
Hola Diego,
according to the 6top draft:
A node MAY support concurren
enough though.
>>
>>
>>
>> what do you think?
>>
>> X
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> 2016-05-18 12:39 GMT+02:00 Lijo Thomas <l...@cdac.in>:
>>
>> Hi Xavi/Diego,
>>
&
ilajosana
> *Sent:* 18 May 2016 17:52
> *To:* Lijo Thomas
> *Cc:* 6tisch@ietf.org; Prof. Diego Dujovne
>
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hi,
>
>
>
> the current 6top draft v00 says:
>
.org] On Behalf Of Xavier Vilajosana
Sent: 18 May 2016 17:52
To: Lijo Thomas
Cc: 6tisch@ietf.org; Prof. Diego Dujovne
Subject: Re: [6tisch] New error type for concurrent transactions on 6top
protocol draft
Hi,
the current 6top draft v00 says:
A node MAY support concurrent 6P Transact
tisch [mailto:6tisch-boun...@ietf.org] *On Behalf Of *Xavier
> Vilajosana
> *Sent:* 14 May 2016 18:34
> *To:* Prof. Diego Dujovne
> *Cc:* 6tisch@ietf.org
> *Subject:* Re: [6tisch] New error type for concurrent transactions on
> 6top protocol draft
>
>
>
> Hi Diego,
>
>
&
.
Thanks & Regards,
Lijo Thomas
From: 6tisch [mailto:6tisch-boun...@ietf.org] On Behalf Of Xavier Vilajosana
Sent: 14 May 2016 18:34
To: Prof. Diego Dujovne
Cc: 6tisch@ietf.org
Subject: Re: [6tisch] New error type for concurrent transactions on 6top
protocol draft
Hi Diego,
Hi Diego,
What I propose is to lock in the schedule the cells that are being sent in
the candidate list, this means that 1) if there are other cells available
in the schedule, the node may still be able to propose another
(non-overlapping) candidate list. thus still supporting concurrency and 2)
Dear all,
I proposed today to add a new type of error
for CellList proposal during the transaction. The idea
follows the solution proposed today at the Webex call
by Xavi to define a lock when two concurrent cell
requests arrive to the node.
For example, if node B requests a cell from
15 matches
Mail list logo
